proposal do disallow syncs of library packages from experimental without approval

[Scott Kitterman]

On Thursday, October 06, 2011 10:03:26 AM Matthias Klose wrote:
> On 10/05/2011 10:47 PM, Scott Kitterman wrote:
> > On Wednesday, October 05, 2011 09:30:22 PM Sebastien Bacher wrote:
> >> To take an example I think porting universe GNOME2 applets to GNOME3
> >> wouldn't be a good use of our time, we better spend the resources we
> >> have making sure our current desktop version is great.
> >> If some people want to work on porting the applications they care
> >> about,
> >> great, otherwise the source can be dropped and will come back once its
> >> upstream or somebody else pick it up and update the code.
> > 
> > I think Gnome2 -> Gnome3 is an exceptional case where that is
> > particularly true.  In general either all that's needed are rebuilds or
> > digging for patches.  I think if we're going to do a transition the
> > developer needs to at least follow through and try to deal with
> > Universe and file bugs where things fail.  I don't think just fixing
> > Main and then saying "Meh, Universe, Whatever" is appropriate.
> 
> We do have more "exceptional cases" like compiler and linker changes, other
> major version changes which are better handled in that the proposed way
> forward is announced (apologies if I did miss it for Gnome2, I only did see
> the release goal getting gtk2 off the images).  The removal of the GNOME2
> applet related packages was done, which is fine, although I assume that
> some effort went into attempts to fix things before the removal of those
> packages.
> 
> "all that's needed are rebuilds" is a lot to do, and it doesn't help if
> major changes are still done after the last test rebuild.  This cycle's
> example is the change in gtk/gnome's pkg-config files moving libraries from
> the Libs to the Libs.private attribute, resulting in build failures (no, we
> don't know which ones are not yet detected, how many, etc, libgnomeprintui
> still not fixed). Such a change is appropriate before feature freeze, but
> not after.  I'd like to challenge the general freeze exception for Gnome
> and KDE for the LTS, if changes like this are more or less blindly applied,
> even if these are found in upstream release candidates.

KDE doesn't need any standing freeze exception now that we are basing 
exceptions on features and not version numbers.  The KDE SC 4.X.0 release 
comes before feature freeze so upstream is only bug fixing after that.  Any 
case from an upstream update that violated Ubuntu's feature freeze would also 
violate upstream's maintenance policy.

Scott K