Vincent Lefevre <vinc...@vinc17.net> writes: > On 2013-04-02 14:29:46 +0100, Neil Williams wrote:
>> That is not how it actually works out. Policy changes are made which >> require old packages to build with new flags, compilers and toolchain >> packages get upgraded and introduce new failure modes, QA tools improve >> and catch more corner cases. Those things no longer happen during a >> freeze, so the bug count has a chance to go down. >> Look at the graphs on bugs.debian.org - the RC count rises steadily >> outside of a freeze. > The graph is meaningless. Many RC bugs can be due to transitions, which > are specific (the freeze applies to *all* packagse). I don't see how that makes the graph meaningless. One of the points of a freeze is that we stop doing new transitions; in fact, that's one of the painful parts that everyone complaints about. How do you plan on keeping transitions from introducing new RC bugs without freezing? > This is also due to the fact that more people are working on fixing RC > bugs *now* instead of doing that before. Of course. And the only thing that we've ever managed to do to get that behavior change is to freeze. If you could get everyone to work on RC bugs outside of a freeze so that the RC bug count doesn't spike and then grow continuously every time we unfreeze, then indeed we would have a much nicer release process. Past experience tells us that's Hard; people work on RC bugs during the freeze and not to the same degree outside of the freeze. >> Again, you're missing the whole inter-dependency issue. A new piece of >> software can introduce / reveal bugs in previously working software. Or >> a previously working piece of software can start to fail because >> hardware has moved on and is able to push more data through the >> software than previously envisaged leading to complex threading / >> timing issues. > But my point is that this is true only for some particular packages Which collectively amount to probably 75% of the archive, since among other things that includes pretty much any package that uses a shared library. > and this doesn't prevent developers from fixing RC bugs. Nothing prevents developers from fixing RC bugs at any time. They just don't in sufficient numbers to keep ahead of the incoming rate except during a freeze, both because the freeze drops the incoming rate (by, among other things, rejecting new transitions) and because more people actually work on RC bugs during a freeze. That's the fundamental constraint that any new release process needs to work with. -- 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/874nfori8t....@windlord.stanford.edu