[ 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.
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
signature.asc
Description: Digital signature
