|| ||Luk Claes <luk-AT-debian.org> |
|| ||debian-project <debian-project-AT-lists.debian.org> |
|| ||Re: Debian decides to adopt time-based release freezes |
|| ||Wed, 29 Jul 2009 12:22:48 +0200|
|| ||Article, Thread
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
We will only release when we are ready to make sure we do not have to
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
>> 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
>> 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
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.
to post comments)