On Thu, Jun 01, 2006 at 10:56:37AM +0200, Sven Luther wrote: > > No, I complained about the kernel team's practice of *coupling* critical > > fixes with irrelevant changes that require NEW processing, just as I would > Bastian said : > -15 will again hit NEW. > And you asked : > And if there are failures again with -15, can we expect a -16 soon that > fixes them *without* needing to add new packages? Which was a request, not a complaint. My complaints come from Bastian's response that no, he did not intend to focus -16 on getting 2.6.16 into testing, regardless of what bugs showed up in -15. > > complain about any maintainer of a base package making a habit of coupling > > critical security fixes with irrelevant changes with the potential to > > introduce release-critical regressions and/or delays on testing propagation. > Like, fixing the missing PReP support requiring the addition of a new -prep > flavour since upstream prep didn't migrate to ARCH=ppc ? That appears to be filed as a severity: normal issue (359025); so yes, I think it's non-strategic to make such a change a precondition for fixing numerous security-related bugs in testing. But I didn't even complain about this change -- I knew it was already pending at the time the mail went out. My complaint was about the unwillingness to prioritize getting 2.6.16 into testing above other changes not yet even *written*. > > very low priority to the needs of users of testing. I do have a *big* > > problem with that, because it should easily be doable to create a short > > branch in svn used only for RC bugfixes for long enough to get a fixed > > kernel into testing; instead, this policy puts the much greater burden on > And it should be easily doable for you to ask the ftp-master to accelerate > NEW processing, or for the NEW processing of the kernel package to be > automated. See how easy it is to put work on someone else ? :) Why would I ask for either of these things? I'm not the one who has a problem with NEW processing, and I don't think *asking* for faster NEW processing is going to do any good. OTOH, I did assume that the kernel team was interested in helping to ensure testing remains useful to our users, so that they'll use it and report problems with it, and that after 15 revisions of 2.6.16 packages this might be worth a bit of coordination in order to get at least one update into testing. Asking the kernel team to briefly direct their focus on getting 2.6.16 into testing is comparable to asking the ftp team to expedite a particular release-critical fix from NEW. It's not comparable to asking the ftp team to refactor how NEW processing works. > > And no, I don't want to be using my position as release manager to ask the > > ftp team for out-of-order processing of completely release-irrelevant new > > packages. I resent being put in that position by maintainers who choose > > to tie release-critical fixes to release-irrelevant changes. I have better > > things to do with my time than being used as a pawn in your squabble with > > the ftp team over NEW processing. > Yeah, except that in this case the new packages was the release-critical fix, > and in the preceding one, it was the refusal of the ftp-master to admit > not-ready-for-prime-consumption kernel packages into testing, namely the xen > flavours. If someone had asked me about expediting the 2.6.16-2 ABI change through NEW, I would have gladly brought it to the attention of the ftpmasters. Nobody asked me. I have no idea why you're presenting this in the context of my objection to the coupling of release-critical fixes to release-irrelevant changes, since that's clearly not the case here, so clearly isn't what I'm complaining about at all. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature