Steve Langasek wrote (elsewhere):
> something changes in the archive (often for a transition that needs
> to happen), a large number of packages are broken by this, and some
> appreciable number of the maintainers don't respond in a reasonable amount
> of time ("reasonable" defined as "sufficient to make headway against the RC
> bug count"; average time to bugfix << average interval between
> archive-breaking transitions).
I wonder if you have any numbers on this? My gut feeling for a while has
been that part of what's keeping the RC bug levels in balance is that
we have a constant stream of RC bugs being filed for issues that are not
new but have only turned up as things get tested. A certian percentage
of these affect stable too. One obvious example is security bugs. It
seems to me that if you look at the RC bug graph, most of the sharp
spikes and dips are due to the kind of transitional RC bugs you're
talking about, which says that we do pretty well at dealing with those,
at least for significant transitions that cause a lot of similar bugs.
One of my problems with our current release process is that it doesn't
seem to take into account the bugs that exist in stable. By the current
metrics we could easily be in a position today where testing has many
fewer RC bugs than stable, but still be far from a release. And even if
we get the RC bugs to zero and make a release, that release will have
many undiscovered RC bugs which will turn up later. That makes it hard
for me to worry about bringing the count down to zero, since it's really
just pushing the iceberg underwater for an instant.
I wonder if it would be worthwhile to try to quantify this some more,
by looking at all the RC bugs over a period of time and determining:
a. What percentage were caused by issues in new uploads.
b. What percentage by transitions.
c. What percentage also affect stable.
and finding the relative time-to-fix of each of these.
--
see shy jo
Attachment:
signature.asc
Description: Digital signature