2012/7/19 Jef Spaleta <jspaleta@xxxxxxxxx>: > On Thu, Jul 19, 2012 at 11:05 AM, Nelson Marques <nmo.marques@xxxxxxxxx> wrote: >> Are you ready to accept patches on GTK+ and potentially on Xorg that >> were declined from upstream? This should be your initial thoughts! > > Can you point me to the relevant discussion for any critical > functionality patches which were actually submitted to the upstream > projects in question and were rejected. I've asked Ken to provide me some additional info on this; I will mail tomorrow or during the weekend the links to this list. >From what I know back then, this patches were needed: - gnome-session + 95_dbus_request_shutdown.patch ( not sure if this is still required, this enabled the shutdown functions to work properly from the session indicator ). - GTK+-2.0 + 012_ubuntu-set-grab-add.patch ( I don't believe this one is used anymore, but this enabled to export widgets through DBus ) + 043_ubuntu_menu_proxy.patch ( to export menus through DBus, this one is still used, and if I understood correctly, this is currently the only remnant of non-upstreamed patches and I believe it was declined by GTK+ upstream, to be confirmed in the next days ) + There were 2 more fixes to properly generate the .gir packages, not much big deal there. The working packages are still here: https://build.opensuse.org/package/files?package=gtk2&project=GNOME%3AAyatana%3A11.4 Those were the sensitive issues back then. I never included the XInput stuff on Xorg and left this stuff behind because it was taking I didn't had back then. > That being said, I'm pretty confident the maintainers of the impacted > packages are not going to take on substantial non-upstream patch sets > to Xorg and Gnome. It really goes against the upstream what is > reasonable ethos of this distribution. I'll remind you again that > Unity isn't packaged in Debian for a reason. I would suggest this deep > vendor patching of shared components is part of that reason. I agree. Like I said, I got warned from Vincent that some patches weren't acceptable to merge with GNOME unless they were upstreamed. I'm not surprised that others feel the same way. >> Forking anything will lead this to nearly unmaintainable unless you >> have someone working fulltime on it ;) > > Then this repository effort will continue to be a non-starter for > inclusion. That is unfortunate. +1; it would be interesting to any distro to also include Unity, though I'm not sure that personally I would use it. > And due to the extensive nature of the package replacement, I will be > actively dissuading anyone from using these packages. I will also be > making an effort to inform community support providers in the irc and > forum support channels to look up for these packages being on a user's > system and to point those users to your preferred support channel for > help with their system when problems arise wit operation associated > with anything you replace including pulse audio and gnome. For the > record, what is your preferred support channel for end-users to use if > they encounter problems after installing these packages? If it was me, I would still try to do what Canonical didn't, some refactoring to code and see if could get it upstreamed to easen up for everyone. I guess this involves a lot of work across several components, but then all the community could benefit from them. If people encounter bugs on this packages, go to the url[1], sounds like the most logical option to me. [1] - https://bugzilla.novell.com/enter_bug.cgi?classification=7340&product=openSUSE.org&component=3rd%20party%20software&assigned_to=vuntz@xxxxxxxx&short_desc=GNOME:Ayatana:%20Bug -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
