Re: list what's in the NEW queue?
Steve Langasek <vorlon@debian.org> writes:
> What I know is that every time an ftpmaster processes a batch of NEW
> packages, a percentage of them wind up in testing with serious bugs for
> failing to declare build-dependencies, and then the release team has to
> track these bugs.
>
> Since the testing scripts have no way to distinguish an
> architecture-specific package from a broken binary that only builds on the
The package-arch-specific file could be utilized. Or you could require
that the intial upload of a package was at least 3 month ago. That
would probably be better so archs can be temporarily ignored for a deb
without altering p-a-s. packages.qa.d.o has the dates for past uploads
from somewhere so a 3 month check should be simple.
(3 month being some randomly picked time period)
> maintainer's system, the only strategies I can think of off-hand that would
> be effective at reducing this problem are to disallow all binary uploads
> from maintainers, to get FTBFS errors detected and filed sooner after
> packages are uploaded, or to cut down on the number of utterly broken
> packages that are getting uploaded in the first place. I'm not suggesting
> that ftpmasters are deliberately ignoring the NEW queue for sarge's sake,
> but from here I'm not shedding any tears.
Any NEW upload should have normal urgency. That would give buildds 10
days to try to build the package and file a FTBFS bug on it. Since
that is RC the package should never reach sarge. With 10 architecture
building it surely at least one admin must have time to file a FTBFS
bug in that time. That is if it is arch: any.
If those 10 days aren't enough what makes you think 15 days or 20 days
time would be much different? In another part of this thread someone
said ftp-master also does some QA on the package, like checking for
policy violations. Wouldn't that include at least one build in a clean
chroot?
Also, a simple remedy would be to make all NEW packages go to
experimental. Since there are now buildds for it for several archs
that would produce appropriate bugreports. That is part of what
experimental is for, right?
Another solution would be to have a buildd for NEW to do a basic
testbuild including arch:all packages.
Having no binary uploads from maintainers enter the archive together
with the source, as you suggested, would be another cure but would
need an arch:all buildd (which is trivial to configure). Not alowing
binaries on source uploads would benefit old packages even more than
new ones imho. Often enough uploads are messed up.
MfG
Goswin
Reply to: