FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 04-03-2011, 04:15 PM
Stefano Zacchiroli
 
Default time based freezes

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
 
Old 04-04-2011, 06:38 AM
Carsten Hey
 
Default 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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110404063818.GA28785@furrball.stateful.de">http://lists.debian.org/20110404063818.GA28785@furrball.stateful.de
 
Old 04-04-2011, 07:05 AM
Raphael Hertzog
 
Default time based freezes

On Mon, 04 Apr 2011, Carsten Hey wrote:
> 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 don't agree with this. You can do _a lot_ in 3 months. So saying "fall"
leaves a big uncertainty in terms of roadmap.

Also when you consider a kernel that comes out every 3-4 months, it means
you might target an older version than what you really need due to this
uncertainty.

We don't need a firm date but the uncertainty should not be bigger than a
month IMO.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110404070550.GL21476@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110404070550.GL21476@rivendell.home.ouaza.com
 
Old 04-04-2011, 08:15 AM
Julien Cristau
 
Default time based freezes

On Mon, Apr 4, 2011 at 09:05:50 +0200, Raphael Hertzog wrote:

> I don't agree with this. You can do _a lot_ in 3 months. So saying "fall"
> leaves a big uncertainty in terms of roadmap.
>
And you know two years in advance exactly what you'll have done and what
you'll want to do for the next three months? I somehow doubt that. And
if I'm wrong, you can use the three months you have on your hands to
polish your packages (and everybody else's). Maybe that way the freeze
can be less than 6 months.

Cheers,
Julien


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110404081507.GC3159@radis.liafa.jussieu.fr">http ://lists.debian.org/20110404081507.GC3159@radis.liafa.jussieu.fr
 
Old 04-04-2011, 09:00 AM
Steffen Mller
 
Default time based freezes

Hello,

On 04/03/2011 06:15 PM, Stefano Zacchiroli wrote:
> On Tue, Mar 29, 2011 at 10:51:02AM +0100, Neil McGovern wrote:
>
>> Time based freezes
>> ------------------
>>
I very much agree that with an increasing complexity
of our distribution that goes together with an increasing
heterogeneity of tools and teams, there will always be
some waiting for something to get fixed/improved. A
particular time to freeze, if one does not freeze too often,
seems like a very good idea, then.

The time-based freeze should be decided together (if
possible) with accepting a constantly usable testing [1].
This way, the release team and the commnity may have
some better understanding what exactly it is freezing.

> Road maps
> ---------
>
To me, it would be interesting to have releases to be
associated with particular new features that are not too
likely to be backported. When there is no such unique
feature, one should not freeze but just continue updating
CUT and help backports where appropriate.

We should all be waiting for those new features to become
functional and stable in Debian, not for the release team
to make a particular decision - even though this effectively
may be the very same thing.

> Freezing what?
> --------------
>

When backports are integrated very closely with the
main distribution, the question what or when to freeze is not
really a question any more, I tend to think.

We do have quite a number of packages, especially in the
scientific world, for which the versioning is very important.
Different users, or even different projects for the same user,
may require different versions. To have snapshot.debian.org
and backports, together with good support for chroots and
virtualisation, which we have, shall be considered more
important for many than the question when and what to freeze.

Many greetings

Steffen

[1] http://cut.debian.net/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D9988AF.9020807@gmx.de">http://lists.debian.org/4D9988AF.9020807@gmx.de
 
Old 04-04-2011, 09:42 AM
Jon Dowland
 
Default time based freezes

On Mon, Apr 04, 2011 at 10:15:07AM +0200, Julien Cristau wrote:
> On Mon, Apr 4, 2011 at 09:05:50 +0200, Raphael Hertzog wrote:
>
> > I don't agree with this. You can do _a lot_ in 3 months. So saying "fall"
> > leaves a big uncertainty in terms of roadmap.
> >
> And you know two years in advance exactly what you'll have done and what
> you'll want to do for the next three months? I somehow doubt that. And
> if I'm wrong, you can use the three months you have on your hands to
> polish your packages (and everybody else's). Maybe that way the freeze
> can be less than 6 months.

Some people work to a plan from one release to the next (and I congratulate
them for managing!) but I think a *lot* of the minor work and QA work that
goes on is less coordinated or organised than that, with sporadic bits of
work towards a goal in fits and starts as people work around real life
commitments, followed by a short-term coordinated push to finish off work
before a concrete freeze date, nearer the time.

A worked example: I might have some vague goals as to what I would like to
achieve in Debian for the next release, immediately following the previous
release (i.e., now). But I have no idea when the release will happen, nor
what else will happen in my life over the next 2+ years. So, we make some
loose commitments and begin work on things.

At some point after that, I'll get a mail telling me we're freezing in a
month, or two months (or whatever), on date X. At this point, the release
is concrete, my goals are either plausible or not, and I will be much more
organised in setting aside time for Debian and polishing off my packages
and ambitions for the release. (and thus I was totally scuppered for
Squeeze).

So if a vague freeze date (such as "Fall 2011") is all we get now, we still
need a firmer *future* date, nearer the time (e.g., "Freeze on Halloween",
announced late August), to allow this sort of work cycle to happen.

Of course, if we had more predictable freeze or release cycles from the
beginning, my work patterns might be different. It's a chaotic system,
with each of us adapting to the current environment :-)


--
Jon Dowland


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110404094225.GB14389@deckard.alcopop.org">http://lists.debian.org/20110404094225.GB14389@deckard.alcopop.org
 
Old 04-04-2011, 10:01 AM
Julien Cristau
 
Default time based freezes

On Mon, Apr 4, 2011 at 10:42:25 +0100, Jon Dowland wrote:

> So if a vague freeze date (such as "Fall 2011") is all we get now, we still
> need a firmer *future* date, nearer the time (e.g., "Freeze on Halloween",
> announced late August), to allow this sort of work cycle to happen.
>
I think that was part of what Carsten was saying.

Cheers,
Julien


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110404100101.GL3159@radis.liafa.jussieu.fr">http ://lists.debian.org/20110404100101.GL3159@radis.liafa.jussieu.fr
 
Old 04-04-2011, 10:50 AM
Ben Hutchings
 
Default time based freezes

On Mon, Apr 04, 2011 at 08:38:18AM +0200, Carsten Hey wrote:
> 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.

The release team has done good work during the freeze. However, I
cannot agree with the overall assessment of this release cycle. The
announcement of time-based freezes, followed by the rapid retraction
and further discussion, was farcical. The apparent result was that
no-one really believed in any stated freeze date, and many packages
were unready when the freeze really did begin.

> One thing that the release team already is improving is communication,
[...]

I do agree with this. I have no complaints about communication
during the freeze.

By the way, as a member of the kernel team I was consulted directly by
the release team regarding readiness of the Linux kernel packages
before some of the release decisions. I appreciate that but I believe
that consultation should be opened to the entire developer base before
any final decisions.

Ben.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110404105048.GG2268@decadent.org.uk">http://lists.debian.org/20110404105048.GG2268@decadent.org.uk
 
Old 04-04-2011, 11:03 AM
Simon McVittie
 
Default time based freezes

I agree with Stefano, pretty much...

On Sun, 03 Apr 2011 at 18:15:52 +0200, Stefano Zacchiroli wrote:
> 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.)

Telepathy does a stable-branch of each major component not long before each
GNOME release, so every 6 months. In the absence of a preannounced freeze
date, we basically need to only release stable-branch versions to unstable
(with development versions in experimental), which reduces the ability to get
real-world testing on the features added by the development branch, and
find/fix the bugs before declaring it stable; chicken/egg?

With a preannounced freeze date, we'd be able to push many of our development
versions into unstable/testing (reserving experimental for only riskier
changes), and become more cautious when we get within 6 months of the freeze
date.

It'd be tempting to say "early testing? That's what (Fedora|Gentoo|Arch)
users are for", but I don't think that's a sustainable approach; finding bugs
is one of the ways in which we (should) help our upstreams.

(When I say "development versions", I mean "upstream release with new features"
rather than "random snapshot which might even work", obviously.)

> 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).

For the squeeze freeze, all packages that were in unstable on freeze day
were pre-approved for the usual time-based migration (by the RT adding a large
initial number of hints), and the RT had a relaxed policy for freeze-exception
requests for a while. If that's not too much work to do again, it seems a good
compromise?

S


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110404110342.GB11492@reptile.pseudorandom.co.uk" >http://lists.debian.org/20110404110342.GB11492@reptile.pseudorandom.co.uk
 
Old 04-04-2011, 11:15 AM
Piotr Ożarowski
 
Default time based freezes

[Stefano Zacchiroli, 2011-04-03]
> Road maps

+1

no, I cannot fix & upload (without waiting for sponsoree who has a list
of things to learn/fix) 10+ RFS packages (postponed mostly due to
packaging bugs), deal with increased number of "normal" RFS mails ("I
was working on improving the package for last few weeks, please upload
it now because the freeze will happen this week"), scan thru 500+ team
packages (to check if every transition is done or to upload new upstream
version that fixes annoying bugs or simply to clear team's RFS list /
upload UNRELEASED fixes), complete transitions (which can take some time,
even for small packages like sqlalchemy¹, not even mentioning PITA
python-defaults transitions²)... in one day/week/month (even with "soft"
freeze for the next month)

[¹] which never were announced to release managers (and never will most
probably)
[²] hint: python2.5 in Squeeze

> Strict date

+1

most of the work is done by our upstreams, and by simply telling
them "we'll freeze PICK_YOUR_MONTH every even/odd year" will (in the long
term) improve quality of Debian *a lot* more than choosing a random^Wperfect
(and different) date for every release cycle (and not announcing it to
upstream authors *at all*), IMHO
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110404111533.GC28369@piotro.eu">http://lists.debian.org/20110404111533.GC28369@piotro.eu
 

Thread Tools




All times are GMT. The time now is 09:01 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org