proposal do disallow syncs of library packages from experimental without approval

Iain Lane laney at
Thu Oct 6 09:39:12 UTC 2011


On Wed, Oct 05, 2011 at 05:21:05PM -0700, Steve Langasek wrote:
> On Wed, Oct 05, 2011 at 04:17:43PM +0100, Iain Lane wrote:
> > On Wed, Oct 05, 2011 at 03:55:54PM +0100, Colin Watson wrote:
> > > […]
> > > > All three cases have in common that the packages were left alone for
> > > > months. The third example could have been avoided if we could check
> > > > build dependencies when syncing, and rejecting the sync when the
> > > > b-d's are not fulfilled (although there should be an override
> > > > option).
> > > I don't want to add extra archive-admin checking to the sync process;
> > > firstly, we're moving towards self-service syncs anyway, and secondly,
> > > as the libav example shows, syncs aren't really special here.
> > > More discipline for library upgrades would indeed be a good thing.
> > > The main problem seems to be library upgrades that don't really have
> > > anyone looking after them (and this is worst when it's Ubuntu-local or
> > > from Debian experimental; at least in unstable the Debian release team
> > > usually cares to some extent).  IMO, we should make it clear that if
> > > you sync or merge a library from experimental then it is your
> > > responsibility to ensure that all reverse-dependencies are ported.
> > Right: if you introduce a SONAME bump (or similar) you should care for
> > it. This cycle the burden has fallen upon those who choose to care for
> > the NBS list, and that's neither fair nor sustainable.
> > Most of these uploads will have to go through binary NEW so that is a
> > good opportunity to check with the uploader that they plan to address
> > the ramifications of the uploads they introduce.
> I don't think this is something archive admins should be expected to do;
> it's not in keeping with the other kinds of archive consistency checks
> they're responsible for.  It's also, in a sense, too late - by the time the
> package hits binary new, the source version is already in the archive, so we
> have to "deal" with the transition in one way or another.

OK. It just seemed like a place where we could have said "has this
developer prepared for the transition they are starting?". I didn't
think there would be any rejections at this stage, just some basic
> Like Scott, I think this needs to be the responsibility of the developer
> starting the transition, and this is true regardless of the origin.  I think
> the point of starting this thread is to get a consensus that this is the
> right way to handle transitions and to *raise awareness* of the issue, with
> a particular emphasis on experimental because pulling in a transition from
> experimental means we effectively have no backing from the Debian
> maintainers for getting it done in a timely manner (i.e., within an Ubuntu
> release cycle).

I'm most definitely not saying that people shouldn't take responsibility
for their transitions. That is pretty much the opposite of what I want,
which is to socialise the idea that transitions aren't something that
you can expect others to clean up after you for — you are responsible
for seeing them through. I think a little bit of pushback will get the
message out. And if it fails to then we can fetch the bigger hammers.


Iain Lane                                  [ iain at ]
Debian Developer                                   [ laney at ]
Ubuntu Developer                                   [ laney at ]
PhD student                                       [ ial at ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <>

More information about the ubuntu-devel mailing list