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

Re: buildd administration




"Steve Langasek" <vorlon@debian.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
usefully NMU.

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 bugs.




Reply to: