Hello, 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 checks. > 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. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] PhD student [ i...@cs.nott.ac.uk ]
signature.asc
Description: Digital signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
