[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: list what's in the NEW queue?

On Thursday 03 February 2005 14:45, Steve Langasek wrote:
> On Thu, Feb 03, 2005 at 02:28:39PM +0100, Frederik Dannemare wrote:
> > On Thursday 03 February 2005 03:03, Marcelo E. Magallon wrote:
> > > On Wed, Feb 02, 2005 at 06:28:58PM +0100, Jeroen van Wolffelaar 
> > >  > As a DD, you can ls /org/ftp.debian.org/queue/new on merkel,
> > >  > daily synced. Beware, there are 2826 files in there atm, so ls
> > >  > via grep or something.
> > >
> > >  And while we are on the subject, what's with NEW not being
> > > processed? Or are we again in the usual "I'll process any package
> > > that I feel like processing" situation?
> >
> > Is it not just that there's too few hands to do the processing?
> >
> > Recently our DPL assigned extra man-power to the "New Maintainers
> > Front Desk" and to the "Debian Account Managers" and with very good
> > results, for what I know. It would be great if he would assign more
> > people to process the NEW queue as well (in context hereto - do all
> > current members of ftp-masters process the NEW queue?).
> Increasing the rate at which new packages flow into unstable is NOT
> something that should be a priority when we're trying to get the RC
> bug count down in preparation of a release.  Show me that there are
> enough people working on release-critical issues for sarge,

You're probably right there's not.

> which 
> requires no imprimatur from the DPL, before you start throwing
> packages that have never even been tested by their maintainer at us
> faster than we already get them.

I see your point if it is really the case that uploads are being done 
without proper testing from the maintainer himself/herself. I am not to 
say if this is practice, but I certainly don't do it myself, and it is 
a pity for those of us who actually ensure proper testing before 

For instance, I have clamcour waiting in the queue and before the upload 
I tested it for weeks on a server of mine, had an ongoing dialogue with 
upstream and a rather important bug was identified and solved.

Now, should an an rc bug accidentially slip into sid despite this, I 
would, of course, be sure to file an rc bug against my own package to 
prevent it from propagating to sarge.

Would it be an idea (post-Sarge?) to not let packages automatically 
propagate from sid to testing after X days. Instead, the responsible 
maintainer would have to explicitly tag a package as 'ready for 
testing' as opposed to the current situation where a bug must be filed 
to prevent a buggy package from propagating? 

Best regards,
Frederik Dannemare | mailto:frederik@dannemare.net
http://frederik.dannemare.net | http://www.linuxworlddomination.dk

Reply to: