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
signature.asc
Description: Digital signature
