Re: buildd administration
"Steve Langasek" <firstname.lastname@example.org> wrote in message
[🔎] 20051213111028.GJ12007@tennyson.dodds.net">news:[🔎] 20051213111028.GJ12007@tennyson.dodds.net...
On Sun, Dec 11, 2005 at 03:46:12PM -0800, Thomas Bushnell BSG wrote:
You have failed to detail any particular difficulty that this causes,
I'm pretty sure I saw him do this already, by noting that it increases the
number of packages that the release and QA teams have to keep track of.
It's great that you're concerned about the portability of the package, but
there are 500+ open RC bugs known to be relevant to the next release, and
1300+ RC bugs all up that affect packages in unstable. Packages with bugs
in the first category add to the release team's workload of
downgrading bugs/NMUing/pestering maintainers/removing packages; packages
with bugs in the second category add to the QA team's workload of figuring
out if maintainers are MIA, whether packages should be removed from the
archive, and so on. Bugs in both categories make it harder for would-be
bugsquashers to sift through the bug lists to find packages that they can
Steve, I'm not sure i agree with what you are saying here, although i do
generally agree with you.
Keep-out-of-testing bugs seem to be fairly common, Especially on packages
that maintainers belive
are not stable enoughto possibly be included in releases.This is often found
in convience packages
such as the weekly cvs snapshots of emacs, which proably should never be
part of a stable release.
It sounds to me like what is needed as a tag for bugs that tells QA (you
post noted that the release team
would ignore RC bugs on packages not in testing) that it can ignore those