[Oneiric-Topic] Reducing number of patches in our packages

[Rodrigo Moya]

On Thu, 2011-04-07 at 20:26 -0400, Jorge O. Castro wrote:
> >> Also, some Ubuntu-specific patches, like the appindicators ones are
> >> duplicated in lots of packages, so it would be good if we could find a
> >> better way to make upstream apps use them, like, for instance, patching
> >> gtk_status_icon_* in GTK itself to use the indicators when available,
> >> instead of having to patch dozens of apps (and keep those patches
> >> up-to-date and working for every major version upgrade).
> 
> How would this affect application authors, would they need to go update again?
> 
what do you mean?

> >> Another candidate for that could be the launchpad integration patches,
> >> which are present in many more packages than the appindicators ones. I'm
> >> sure we can find a way to have that in GTK itself, so that whenever a
> >> Help menu is created, and given we have the name of the app, it could
> >> just create the LPI entries.
> 
> This would be great, do you think GTK upstream would be keen on this?
> 
maybe, but if not, we would just need to carry 1 distro patch, not
dozens of them

> > +100 for this topic.  The amount of patches we carry is a huge but
> > mostly silent overhead.  I'd like to make a website like versions [1]
> > that shows our diff against vanilla GNOME to make this more visible.
> 
> I would like to also +100 even though I'm not on the desktop team. :p
> 
> The 3.x transition this is the time to get this out of the way before
> we find ourselves in LTS-crunch with too large a delta. When we're
> ready I'd like to see us approach d-d-l as soon as possible and start
> talking to module maintainers and start working on this. Even if we
> don't get them all if we could at least do a frontloaded approach for
> O and catch the remainder in P that would be great.
> 
right, that's why those patch upstreaming/cleaning days would be useful