Re: Debian decides to adopt time-based release freezes
Sandro Tosi wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Debian decides to adopt time-based release freezes
No, the project DID NOT decide it, the release team did, and the
project has to accept it; there's a lot of difference.
No, the Release Team proposed a plan. The project is free to accept or
refuse the plan. Of course refusing the plan will have its consequences
within the Release Team as well as within the project.
The Debian project has decided to adopt a new policy of time-based
development freezes for future releases, on a two-year cycle. Freezes
and what are the real advantages of this? I saw none in this announce.
The main advantage of a time based freeze would be that developers have
a clear idea about when the cutoff is for new features and when the
period of stabilising to a release starts. This should give developers a
better chance to plan and more responsibility in how they want to
support their packages.
will from now on happen in the December of every odd year, which means
that releases will from now on happen sometime in the first half of every
even year. To that effect the next freeze will happen in December 2009,
with a release expected in spring 2010. The project chose December as a
suitable freeze date since spring releases proved successful for the
releases of Debian GNU/Linux 4.0 (codenamed "Etch") and Debian GNU/Linux
5.0 ("Lenny").
if time-based is REALLY needed, why then not "freeze on even Dec and
release on Spring on odd years"? this will allow the current release
cycle to have enough time to achieve something, while letting
time-based proposers happy.
The main reason is that we now have the momentum to try a time based
freeze and that delaying the freeze would cause developers to 'forget'
about what a time based freeze is about.
Time-based freezes will allow the Debian Project to blend the
predictability of time based releases with its well established policy of
feature based releases. The new freeze policy will provide better
predictability of releases for users of the Debian distribution, and also
bullshit! we are trading quality for what? We release when it's ready,
not when the clock ticks. it's completely a non-sense, and it's
generating only bad feelings in developers and users.
Hmm, you put it very negative while the intention is not at all how you
put it:
We will only release when we are ready to make sure we do not have to
trade quality.
We will freeze on a upfront specified date to give developers a chance
to better plan what should be included in the release.
and predictability is the only advantage of this proposal? if so, then
simply let's drop it: pro and cons are damn wrong.
No, see above.
allow Debian developers to do better long-term planning. A two-year
release cycle will give more time for disruptive changes, reducing
Not this time.
True, this time we want to make sure we have the momentum to do a time
based freeze and maybe get some developers to think about shorter time
plans.
inconveniences caused for users. Having predictable freezes should also
reduce overall freeze time.
should we remember here that lenny freeze took +6 months?
Note that how long the freeze takes is the responsibility of all
developers as the most important measure (RC bugs) can be influenced by
everyone.
The new freeze policy was proposed and agreed during the Debian Project's
yearly conference, DebConf, which is currently taking place in Caceres,
Spain. The idea was well received among the attending project members.
1. what about the developers that couldn't come to DC? don't we
deserve to be asked for our opinion? are we of a lower class? is this
a decision only made by a team and then you want to us to pretend the
whole project decided it?
Not at all. The Release Team proposed a plan and it was welcomed during
the team's keynote at DebConf. But your and others input is very much
appreciated.
The announcement was made to be sure that press coverage would not
differ from the actual message and confuse people. It seems it has not
reached that goal completely, though the intentions were good.
2. it doesn't seem all the attendants agreed with it, given what
happened yesterday evening on #debian-release.
I don't know what happened yesterday evening on #debian-release.
To conclude:
- - we are giving up our quality-based release for a time-based one
for no particular reason
Not at all.
- - there is a constant drift away from debian by our users, this
would be the killing shot
Why? We do try to take into account considerations to improve the usability.
- - this is a change in our most important aspect of our work: the
release. How can I go now to my boss and propose to switch to debian
once this is happening?
You could propose the skip one release if needed.
Cheers
Luk
Reply to: