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
wrote:
> > > > 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
uploading.
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://qa.debian.org/developer.php?login=Frederik+Dannemare
http://frederik.dannemare.net | http://www.linuxworlddomination.dk
Reply to: