[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: time based freezes

[ Bcc:-ing release team ]

On Sun, Apr 03, 2011 at 06:15:52PM +0200, Stefano Zacchiroli wrote:
> 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!

Another thread, another thread summary! Here is a summary about where we
are on this discussion, at least as far as I can tell.

- The general of concept of time-based freeze seems to be
  uncontroversial. Apparently (and unsurprisingly, if I may) people
  would love to have a date early on to base their roadmaps upon.

- The choice of having a specific date seems to be more controversial
  (although honestly I don't see how it could do any harm). Anyhow, it
  seems noone would object to have a target freeze month at the
  beginning of a release cycle, seeing it refined later on. Various
  people have argued that the target freeze month shouldn't be larger
  than one month, and I personally agree with that: having a larger
  period has IMHO the potential to introduce back some of the planning
  issues we have seen during the Squeeze cycle.

I would love if we can summarize the above part by saying that we have
consensus on: 1) announcing at the beginning of a release cycle a target
freeze month, 2) refining it later on.

Regarding a more precise definition of "later on", I agree that for DDs
it wouldn't make much of a difference, but things might be different
from usptream, on which we have way less control. As a rule of thumb, I
believe it would be useful to put a limit like the following: the exact
freeze date will be announced 6 months before the freeze, the
latest. That would IMHO enable those upstream who care about Debian to
reliably plan their releases in order to better collaborate with us.

- The question of "what" to freeze seems to be uncontroversial as well,
  the scheme of pre-approving packages used for the Squeeze freeze
  (which I overlooked in my kickstart mail) seems to be appreciated.

- On the other hand, a wide open front of the discussion is *when* to
  freeze, with various people arguing in favor of having a specific
  period, such as "we freeze on $month every even/odd year".

  I've sympathies for such a schemes myself, if only for the simplicity
  to grasp and remember it "by heart". Let's look at some data about
  that. I observe that Debian has released every 24 months (+/-2) since
  the days of Etch in 2007. Even if we include Sarge, which has had a
  particularly long release cycle, the average is still around 25
  months. Freezing every 24 months will be compatible with such a trend
  (assuming it will continue, see below for a related question). If for
  instance we say we freeze in August (or pick your month) every
  even/odd year, that would allow us to release in February, in case RC
  squashing would proceed as it did for Squeeze.

  No objections have been raised to such a scheme up to now and I would
  welcome it as well, as it could bring roadmap advantages for both DDs
  and upstreams. The only problem is ...

- ... what to do if a development cycle (i.e. the period from the
  previous release to the next freeze date) would turn out to be "too
  short"? That could happen when the previous release takes more than 6
  month to stabilize and to get RC bug cleaned. I believe the figures we
  are talking about give enough margin not to worry too much about it.

  Let's assume for example that Wheezy would freeze (as an entirely
  hypothetical scenario) on August 2012 and that it would take a whole
  year to stabilize and release it on August 2013. That would reduce by
  6 months the release cycle of Wheezy + 1, but still leave 1 full year
  of development from August 2013 to August 2014, the "standard" freeze
  date. Considering that 1 full year for stabilize a release should lead
  us to worry in general about the well-being of our project (or about
  the specific software choices we made in that cycle) and that even in
  that case there will be 1 full year of development to catch up, I
  think such a scheme would be a reasonably safe bet.

  I do think it's worth going there (freeze every 24 months on a
  specific month), but I wanted to mention the above risk nonetheless,
  as it is an important one to keep in mind.


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

Reply to: