On Tue, Mar 29, 2011 at 10:51:02AM +0100, Neil McGovern wrote:
> Time based freezes
> ------------------
> We're aware that there is an outstanding discussion to be had about time
> based freezes (note: _not_ time based releases).
>
> The beginning of a release cycle seems the ideal time for that
> discussion and we hope to be in a position to start it after processing
> the results of the retrospective.
Since other follow-ups have avoided this topic up to now, let me be the
reckless guy who jumps into it with both feet: time based freezes!
Road maps
---------
I believe we need time based freezes. Even more radically, I believe we
need to know the freeze date as soon as possible, e.g. no later than a
couple of weeks after the preceding release. (Obviously, transitioning
to time based freezes warrant exceptions to the rule.)
My rationale for the above is simple: *road maps*. Each team and
individual developer should be able to define their own road maps very
early in a release cycle. Doing so will help teams in planning and
splitting work. I believe it will also help maintainers in negotiating
release dates with upstreams which are sensible to distribution needs.
Strict date
-----------
The difficult part in moving to such a scheme is that the freeze date
must be strict.
That is the case because, as history has taught us, announcing a freeze
date and not respecting it---or, equivalently, have announced freeze
dates which are generally believed to be only indications---will spread
frustration among developers. That is so because inevitably maintainers
will show different sensibilities towards a freeze date which is
perceived as not being strict. Some maintainers will almost ignore it,
possibly rushing up work at the last minute, forcing the release team to
postpone the actual freeze. In the meantime, others will perceive the
initially announced date as strict from day 1, plan accordingly, and
ultimately suffer of important out-of-dateness due to freeze
postponement.
All the above, for me, justifies having a strict freeze date very early
in a release cycle.
Freezing what?
--------------
The next question is then what does "freeze" means. Does it mean that
automatic transition to testing stops automatically at freeze date, or
rather that no new transitions are accepted anymore (which IIRC has been
proposed before). I'm tempted to prefer the former, as it seems to be
more fair. However, it's also clear that at the freeze date there will
be transitions which are just half way through. I'm unable to judge if
for those situations it will be better for the work of the release team
to keep testing going on automatically or not ... comments?
All in all, I quite like the idea of a strict freeze date + a flexible
period during which exceptions are granted in a more liberal manner, as
it has happened for the first weeks after the Squeeze freeze.
Freezing when?
--------------
A couple of sub-questions are related to the question of when to
freeze. One is whether we should aim at having a fixed length of a
development period (e.g. 1 year of development from the day the previous
release occurred) or rather aim at having a freeze date occurring during
a specific month of the year, to coordinate the choice of upstream
versions with other distros. The latter is quite constraining and scares
me a bit, but I've also heard from various teams (e.g. kernel and
security) that having synchronized versions with other distros do help
in sharing patches and long term maintenance plans.
A scheme that could work is deciding that we'll have a development
period of a specific length (1 year?) with a specific tolerance (+/-2
months?). At the beginning of each release cycle, the release team will
announce a freeze date contained in such a time window. The choice of
the freeze data is within the responsibility of the Release Team
already; if people will vehemently disagree with the decision, they have
mechanisms to overrule the decision as well. Having the announcement
occurring at the beginning of the release cycle will help in reducing
the negative effects of changing the decision, in the hopefully unlikely
case that people will really want to do that.
Let's fight^Wdiscuss all this!
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams
Attachment:
signature.asc
Description: Digital signature