Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Neil Williams wrote:
> On Mon, 01 Apr 2013 00:48:08 +0300
> Uoti Urpala <email@example.com> wrote:
> > Philipp Kern wrote:
> > > Thanks for trading the R release cycle with Debian's and for delaying the
> > IMO it's important to remember that it's fundamentally the release team
> > that is at fault for problems here, not the R maintainer.
> The length of the freeze is not the fault of the release team.
> The length of the freeze is down to all of the contributors to Debian
> not fixing enough RC bugs - I count myself in that, I've managed to get
> massively less done for this release than for previous ones. There are
> reasons, it doesn't change the reality that the freeze is still ongoing.
IMO it is at some level the fault of the release team, either in setting
the goals for the release or in carrying out the implementation of those
goals. Package maintainers were able to keep unstable in a much better
shape before release freeze, and I see no reason to believe they would
have failed to continue if not for interference from the release
process. And there is no inherent reason that a release would have to
interfere that badly.
Perhaps the task of making a release with existing resources is simply
too hard, so that the people trying to do the work should not be blamed
overly much for failing, and instead the goals should be lowered. But
IMO it's a fact that the release management has been a failure; the
release process has caused problems for users and upstreams, and the
release will once again be largely obsolete by the time it's out.
> The release team have been looking for help to triage unblock requests
> and some help has been given, but even if unblocks were all handled,
> there remain too many RC bugs and that is and always has been the core
> The release team are not responsible for fixing RC bugs - that's down
> to the rest of us.
> Release-critical bugs delay releases, not the release team.
Note that my main criticism was not about the delay of the release
itself, but about the harm the release process causes to unstable.
Unstable matters to both users and upstreams (and probably several
derivatives too). Having latest upstream versions easily available to
users is important for the development of many projects, and IMO Debian
is big enough that it keeping users of even unstable on old versions is
a serious issue.
I see the Debian release situation as closely analogous to how big banks
were bailed out with taxpayer money due to being "too big to fail"; the
release process is similarly "too big to fail". In most cases, if
developers can't implement something without seriously harming users and
other developers, then they simply can't do it. But if the release team
lacks the competence or resources to create a release without hurting
users and other developers, then they get to hurt them, as completely
failing to release is seen as an unacceptable alternative.