Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Vincent Lefevre <vincent@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: