Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
On Mon June 2 2008 17:38:53 Lucas Nussbaum wrote:
> On 02/06/08 at 15:04 -0700, Mike Bird wrote:
> > "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".
>
> Your proposed solution doesn't allow testing to converge to a releasable
> state. The only solution you are offering is "do nothing".
Lucas,
The current 20-day policy only applies to "leaf" packages. I don't
know which definition of "leaf" is intended, so let's assume that
it refers to packages referenced in Pre-Depend, Depends, and
Recommends but not Suggests, as that roughly matches aptitude's
default behavior.
Of approx[1] 21828 Lenny packages which we track, approx[1] 10514
or 48% are non-leaf and therefore excluded from the current 20-day
policy. (If Suggests dependencies are included the latter figure
rises to 12786 or 59%).
Therefore it cannot be said that the current policy addresses the
issue you raise, as half of the packages are immune to the 20-day
rule. There is merit to your observation, but it is a different
issue.
> 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?
The release team has always in the past used a process of making
DDs aware of RC bugs and RC bug counts during the release cycle,
particularly during the later stages. The process works. One
might wish it worked better, but at least it doesn't cripple the
"Debian Desktop Edition" for most of the release cycle.
> You have to propose a valid alternate metric and then implement
> code that allows to keep track of this metric.
The code for the metric needs no changes. What is needed is
to avoid distorting the metric by prematurely excluding RC
bugs from Testing and from the metric.
The RC-bugs-in-testing metric is actually a better metric for
not artificially excluding RC bugs from testing. A better
metric gives better control of the release process.
This is a useful (but unintended) side-effect. The principal
goal remains that Testing should be usable for new desktop
installations for most of the release cycle.
> 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.
There is a single list of RC bugs which, if not excused, cause
packages to be excluded from the final release. I see no reason
to change this.
--Mike Bird
[1] These figures are approximate because we include a few packages
from unofficial sources and we exclude a few Debian packages.
Reply to: