Re: On management
On Wed, Feb 28, 2007 at 02:58:12PM +0100, Josselin Mouette wrote:
[...]
> of people running experimental. As GNOME 2.18 is scheduled in two
> months, this means we will be lagging two versions behind upstream as
> soon as we have released.
What's wrong with that? Many packages lag behind. The kernel, for
instance, will also lag two versions behind upstream. OpenOffice.org
will be version 2.0.x, while upstream has recently released 2.1. Heck,
even my pet package nbd-server is lagging behind by a major version (2.8
vs 2.9).
Yes, sometimes we have to make a choice which then eventually turns out
to have been suboptimal. But the world won't end because we don't have
the l33test version of GNOME in Debian; there's Ubuntu for that (and
this is meant neither pejoratively nor negatively).
Management is all about making choices based on available data and on
risk assessments. Given the data that was available to the release team
and the GNOME team at the time the decision was made, I do not think the
choice to stick with GNOME 2.14 was wrong. It may turn out to have been
suboptimal; but that doesn not mean it was the wrong decision at the
time.
As it turns out, getting GNOME 2.16 into etch would have been possible,
so I agree that it's a pity it did not happen. However, we did not and
could not know this back in September. Had we made the decision to go
with 2.16 at the time, and had we ran into problems with doing that,
then we might very well have been in the situation today that GNOME was
currently delaying the release, rather than the kernel. I'm quite sure
you prefer the current minor inconvenience over the alternative where
people might have been bashing you all over the place for not getting
your act together in time.
> Not only did it generate more work as we had two GNOME versions to
> maintain during the freeze, but it is now generating a lot of
> frustration because this extra work looks like a loss of time.
The choice to get GNOME 2.16 into experimental was your own. While I
could understand your frustration for lost time, it's hardly an argument
for good (or bad) release management.
> It is my belief that such things could be avoided if we had proper
> release management.
I'm quite utterly convinced that this is not true. I do agree that the
release team made a bad call in deciding what would go into etch and
what wouldn't. However, that bad call was related to GNOME -- it had
everything to do with the kernel. GNOME was ready in time, but the
kernel unfortunately isn't.
Given that the release team made a single bad call in co-deciding which
major subsystems could go in etch and which couldn't, I think they did a
fairly good job. It's a pity they couldn't do better, but that doesn't
mean they're not doing "proper release management".
[...]
--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
Reply to: