On Thu, Jun 01, 2006 at 01:27:40AM -0700, Steve Langasek wrote: > On Thu, Jun 01, 2006 at 08:15:42AM +0200, Sven Luther wrote: > > On Thu, Jun 01, 2006 at 10:59:36AM +1000, Anthony Towns wrote: > > > On Wed, May 31, 2006 at 07:50:23AM +0200, Sven Luther wrote: > > > > Anthony, ... > > > > I would like to hear your comment on the possibility to override the > > > > need for > > > > NEW for the creation of some new binary package [...] > > > > Sven, you bring this up every chance you get, please stop it. You're not > > > interested in comments, you're just hoping that you'll get a different > > > answer to the last dozen times you've brought it up. > > > Wrong, i bring it up each time there is evidence that there is some needs in > > this area. Three events brought it up here : > > > 1) Hans wrote some things about there not being enough ftp-masters, to > > which > > you responded. > > > 2) Steve as RM complained to the kernel team that he can't get timely > > updates to the packages into testing, because some sub-packages are > > waiting > > in NEW > > 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? > 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 ? > Remember that one of Joey's initial complaints was that the kernel team Yeah, and have you noticed at which speed the kernel upstream has been issuing security-updated 2.6.16.x releases ? > hasn't left any time between uploads to make propagation to testing > possible. This, and Bastian's reply that the kernel team does not intend to > let concerns about testing propagation delay kernel work (apparently > regardless of importance) shows that the kernel team effectively gives a Indeed, this is in accordance of the DPLs electoral moto under the header 'vitality'. Let's do the work fast and early, and not bother about artificial hurdle and delays. > 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 ? :) Alternatively, since the DPL has closed the door to any discussion abotu the NEW queue, the ftp-masters could chose someone of the kernel team as ftp-assistant with the express power to only handle kernel packages. I am sure we can find someone, i would volunteer myself if i would be acceptable to the ftp-masters. > any developers who *do* care about testing's users to figure out how to get > these security fixes into testing without the benefit of the preferred path > (i.e., via unstable). Yeah, and the DPL and you ping-ponging the responsability of NEW handling helps how ? > 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. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
