Michael Gilbert <mgilb...@debian.org> writes: > Or the project could end up in a perpetual freeze. Every time the > floodgates are opened, another 1,000 bugs could get reported due to all > of the new transitions, and another freeze will need to happen to get > those down.
I would like to see us try it and see if that happens. If that does happen, I think that's a fascinating data point, and one that would be well worth the few months of difficult process in order to confirm. Knowing for certain whether or not that would be the outcome would be wonderfully clarifying and helpful in narrowing the possible solution space. > On Sun, May 12, 2013 at 4:00 PM, Russ Allbery wrote: >> Think of this in software development terms. We're currently following >> a development model where, immediately following a release, there's a >> nearly complete free-for-all without much enforcement of bugs or >> regressions. We do that for a year, and then we try to stabilize the >> results. Most free software projects that used to follow this model >> (and there have been quite a number of them) have had similar struggles >> with the extended stabilization process this requires. That's part of >> the shift towards test-driven development, continuous integration, and >> constantly-usable master branches. > Those other distributions have also given up on producing high-quality > releases. Only Debian and RHEL remain in that category. I don't believe that's true; in fact, it's the exact opposite of the outcomes I've observed in practice. Most projects that use test-driven development, continuous integration, and constantly-usable master branches maintain a significantly higher level of quality than the projects that use development methodologies like Debian's (at the cost of forcing disruptive changes to be done more slowly and with more planning, or to be postponed if people aren't available to do them properly). >> The bug affects the version of the package in testing. I see what >> you're saying, but I don't think this is something the BTS can >> represent. And those bugs *are* all release-critical: they have to be >> fixed before we can release jessie, at least unless we're going to >> abort the transition, which seems unlikely. > There is the "sid" tag, which indicates that the issue only affects > unstable. Although I think a "triggered-by" function is needed in the > bts. For example, bugs with "triggered-by gcc 4.8-0" would not be > marked as affected in suites that have gcc versions prior to 4.8-0 > (i.e. jessie would not yet be affected by the gcc transition). If there are no RC bugs affecting the version of a package in testing, that should mean that nothing has to be done to that package in order to release. If the package has to be fixed due to a transition that will be in the next release, that is an RC bug affecting the version in testing and should be counted accordingly. The package cannot be left unchanged and still go into the release, which is the definition of RC. In other words, I see no point in doing what you describe. So far as I can tell, all it does is artificially lower the RC bug count in the graph, while in no way reducing the amount of work that has to happen before jessie is releasable. In other words, it just hides a bunch of RC bugs from the statistics without actually changing their RC status. That seems like an even worse state: we have just as much work to do but now we're hiding that work from ourselves. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5bk3p68....@windlord.stanford.edu
