2012/7/19 Jef Spaleta <jspaleta(a)gmail.com>:
On Thu, Jul 19, 2012 at 11:05 AM, Nelson Marques
> 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:
+ 95_dbus_request_shutdown.patch ( not sure if this is still
required, this enabled the shutdown functions to work properly from
the session indicator ).
+ 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:
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
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
> 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
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, sounds
like the most logical option to me.