Re: time based freezes
The release team did again a great job the past release cycle and
managed to release again a version Debian can be proud of :) There were
of course things that could be done even better next time, but handling
such a enormous task without such issues seems to be impossible.
One thing that the release team already is improving is communication,
for example, they did ask for feedback and welcomed comments in their
mail to debian-devel-announce. One example of less outstanding
communication that happened during the past freeze is that
squeeze-updates has been announced without any prior discussion.
Important aspects of proper communication include comprehensible
justification of decisions and also predictability. As part of an
explanation they once wrote "DebConf should definitely not fall into
a freeze and that we should leave time after DebConf to ..." in an
announcement. A year later they did the opposite and froze at the end
of DebConf. Other reasons that were considered internally like
synchronisation with other distributions were missing in this first
mentioned announcement.
The other thing that has potential to be improved is the freezing.
The relevant part of freeze history is in my opinion:
* There were two mails from the release team regarding uploads on d-d-a
in the week before Lenny was frozen.
* Contrary to what was communicated earlier, Squeeze was frozen weeks
before most people expected it and before the announced Perl
transition has happened.
If the release team would skip those "we freeze next week" mails, there
wouldn't be such a flood of uploads just before the freeze.
If they would additionally stick with what they announce, nobody would
complain that a freeze would have happened unexpected.
* Stefano Zacchiroli [2011-04-03 18:15 +0200]:
> On Tue, Mar 29, 2011 at 10:51:02AM +0100, Neil McGovern wrote:
> > 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.)
I believe we need to know a vague time frame for freezing instead.
With your proposal the release team might announce:
We released on the 7th of February 2011 and freeze Wheezy one and a half
year later on the 7th of October 2012.
With mine they could announce:
We released in February 2011 and we want about one and a half year
between a releases and the following freeze, so we freeze in fall
2012.
> 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.
Both would address the roadmap issue.
> I believe it will also help maintainers in negotiating release dates
> with upstreams which are sensible to distribution needs.
Deciding whether this would be a good thing could be highly
controversial.
> Strict date
> -----------
>
> The difficult part in moving to such a scheme is that the freeze date
> must be strict.
We are in the good position to have a very experienced release team that
is be able to decide whether testing is in a good condition to be
frozen. It should also have option to adapt their time planing to the
team's responses to "what are your plans for stable+1?" mails or to
events that can't be known a few weeks after the prior stable release
has happened.
> That is the case because, as history has taught us, announcing a freeze
> date and not respecting it
Avoiding not respecting announced time frames or dates should not be
that hard.
> ---or, equivalently, have announced freeze
> dates which are generally believed to be only indications---will spread
> frustration among developers.
This time frame could be rather imprecise at first and narrowed over
time.
> Freezing what?
> --------------
>
> The next question is then what does "freeze" means. Does it mean that
> automatic transition to testing stops automatically at freeze date,
This seems to be suboptimal (probably it's just your wording). The
following quote from a mail sent by the release team in 2008 describes
how it also has been handled for Squeeze:
| Packages that are present in unstable the day we freeze will be
| automatically allowed into testing, that is, the freeze date ... does
| not mean your package should be in testing by then, but only in
| unstable.
> 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.
The basic idea of a more flexible period is great, but it was not
properly communicated via debian-announce.
> Freezing when?
> --------------
>
> 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.
Regulation instead of using common sense is in my opinion not a good
choice to take such decisions, especially given that we talk about one
of Debian's core team.
I hope the release team carries on with their great work and maybe even
improves it where possible, e.g., by learning from the past.
Carsten
Reply to: