Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
On 02/06/08 at 15:04 -0700, Mike Bird wrote:
> On Mon June 2 2008 14:39:01 Joerg Jaspert wrote:
> > Feel free to work on an alternative algorithm to manage testing in a
> > different way, fixing what you currently dont like.
> > I am sure that, if you get the work done, the release team will take a
> > look at it.
> > Of course that involves actually doing the work, Im sorry for suggesting
> > that.
> Hi Joerg,
> It is my understanding that the 20-day RC removal is release
> team policy implemented manually. The steps to fix this bug
> are therefore:
> (1) Identify the problem [done].
> (3) Offer a solution [done] - specifically - "don't create 20-day
> removal hints for packages with RC bugs except when its too
> late for a fix to be included in the forthcoming release".
> (3) Persuade the maintainer (release team) to accept the solution [WIP].
Your proposed solution doesn't allow testing to converge to a releasable
state. The only solution you are offering is "do nothing".
How will the release team know that it's late enough to start
removing packages, if the stats are cluttered by hundreds of RC bugs
noone cares about? You have to propose a valid alternate metric
and then implement code that allows to keep track of this metric.
For example, if you provided two lists of RC bugs (those in packages
that will be removed if not fixed, and those that we need to address),
and graphs for the number of bugs in each class, maybe you could try to
convince the release team that it's useless to remove packages from
testing that early.
| Lucas Nussbaum
| firstname.lastname@example.org http://www.lucas-nussbaum.net/ |
| jabber: email@example.com GPG: 1024D/023B3F4F |