Re: Shouldn't we have more ftp masters ?
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
Reply to: