Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-02 09:48:34 -0700, Russ Allbery wrote:
> 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?
Transitions can occur in unstable. But their migration to testing
would be blocked. This doesn't need a freeze.
> > 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.
Perhaps some kind of freeze should occur earlier, i.e. when RC bugs
start to become high, and unfreeze when the number of RC bugs is
low enough.
But I think one needs to differentiate:
* RC bugs in testing and RC bugs in unstable only;
* RC bugs from upstream (which shouldn't require much work from
Debian if upstream is active) and Debian-specific RC bugs.
> >> 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.
I don't understand what you mean here. If you mean that a shared
library is breaking many packages, then such a bug should be fixed
ASAP or the version should be reverted until the bug is fixed. The
package wouldn't probably have the time to migrate to testing anyway.
> > 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)
New transitions should be rejected in some other way, not by freezing
all the packages.
> and because more people actually work on RC bugs during a freeze.
Then perhaps call it a RC big fix period, where people should work
on RC bugs, but blocking new packages that fix bugs to experimental
or unstable is not a solution in particular if the freeze lasts a
long time.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Reply to: