Re: Debian decides to adopt time-based release freezes
Hi,
Marc Haber wrote:
Our 18-to-24-month release cycle was a nice vehicle to stay
asynchronous with Ubuntu, which _I_ consider a desireable feature to
prevent Debian from perishing.
It's easy to say stuff like this, but really, the Debian project at
large has done *no* introspection of what went well and not so well
during the lenny cycle. The installer team had IRC meetings to draw
conclusions for the future, the release team did and the keynote seemed
to reflect their thoughts that (mind you, during the talk, Luk
introduced the subject with "The release team thinks about going to a
time-based freeze", it seems unfortunate that it was declared a done
deal during on the way, but the start is harmless enough), maybe some
others did, but I have missed an review of the lenny release process on
the project level (well, beyond people saying any and every problem
would have been solved by more release updates, 'cause how should any
one know that there are RC bugs to fix if it isn't announced).
After the talk Bdale commented about the length of the freeze and the
made observation (actually had a "complaint") that the length of the
freeze is something were not the release team, but the project at large
should ask itself what to do better. That has not happened. And that why
you have so many RC bugs, including so many trivially fixable ones.
If something poses the risk of Debian perishing it is *not* the
questions of if Debian releases a month before or after Ubuntu, but what
it releases. And not whether the Nautilus minor version higher or lower,
but of what quality the releases are.
Debian's main advantage over Ubuntu is that the (allegedly) higher
quality, not that it releases on a different date. But that comes from
people actually working on producing quality releases. In order to keep
people working on quality releases and keep the freeze short, the
day-to-day quality of Debian-packages has to be improved. Yet, of the
many people crying wolf over too many RC bugs being currently open, how
many actually work on fixing some?
The problem of lenny's long freeze was in part that there was so few
people working on the release and on fixing RC bugs. And that deficit
also shows in the quality of lenny. If people feel that flamewars are
needed to keep Debian relevant, how about flaming the people sitting on
their unfixed RC bugs instead of always focusing on the release team?
What is wrong with everybody who is not outraged by having five hundred
RC bugs not seeing maintainer attention for more than a month?
You know what another great way is to make Debian irrelevant? Make sure
that releases are impossible because nobody wants to be the release manager.
Cheers
T.
P.S.: Mind you, my impression about the "momentum" that the release team
wants to not loose was that they wanted to make a freeze and
release while everybody still remembers the pain of lenny and has
the impetus to do things better this time. Obviously if you never
had that impetus, that is quite difficult to achieve.
--
Thomas Viehmann, http://thomas.viehmann.net/
Reply to: