Some backpedaling on Debian freeze dates

Hi,

sorry for sending out this mail so late. It should have gone out a bit
earlier, but the delay allowed us to update our views on the timeline
based on the feedback we received by the community - see below for
details.

Please read the full mail, as there are important information regarding
the release cycle. Doing a release involves lots of planning and working
together, and we hope to do it yet another time.


Team changes
============

Adam D. Barratt (adsb), Felipe Augusto van de Wiel (faw) and Jurij
Smakov (jurij) joined us as release assistants. Let's welcome them in
our team.


Release Goals
=============

Again for this release we have Release Goals. Please let us remember
first what Release Goals are:

 * Release Goals are goals that should be reached for a better overall
   quality of Debian, without them being Release Critical issues.
 * Open issues can be handled mostly as open release blockers by
   developers, i.e. that means that packages can be NMUed like with open
   RC bugs.

To get a bit better overview, we decided to make a canonical list of
Release Goals. For better structure, and to ease the work for all of us,
Release Goals have some preconditions:

 * Each release goal must be associated with one or two single
   developer(s) who should be able to give a status overview when the
   release team needs that information.
 * The (approximate) number of issues to be fixed needs to be identified
   (and most of them should be ready to filed as bugs).
 * There needs to be a long-term strategy to fix all filed bugs. If
   possible, all bugs should be filed with a patch or some instructions
   how to solve the problem.
 * There needs to be a long-term strategy that prevents new occurrences
   of this issue.
 * A wiki page needs to be maintained with current information about the
   Release Goal

If these conditions are fulfilled, the responsible developers can ask
debian-release@lists.debian.org to confirm a certain release goal. They
can (of course) also propose a short name for tagging the bug reports.

We will keep an authorative list of release goals as part of the release
policy on release.debian.org. If you are unsure who is responsible for
something, you will be able to simply look this up.

The following goals for Squeeze have been identified up to now:
 * multiarch
 * boot performance
 * high quality packages (piuparts clean and other QA subgoals)
 * prepare for the new package formats
 * remove obsolete libraries
 * add kfreebsd-amd64 and kfreebsd-i386
 * full IPv6 support
 * large file support


Of course, besides trying to match these goals, we definitely need to
get rid of all the RC bugs.



Architectures
=============

As some of you might have noticed, we added the architectures
kfreebsd-i386 and kfreebsd-amd64 to testing. This is not a promise that
they will be part of Squeeze, but we consider it realistic. Adding them
early to testing makes it easier for us to get testing into shape. As of
now, these architectures don't have any effect on the testing migration.
Bugs specific to these architectures are not release critical.

However, two architectures also have issues we need to bring to your
attention: We sent mails to the porters of both alpha and hppa that we
need at least a plan how and when the open technical issues are to be
resolved. For details, please see the mails to the porter lists [0] [1].



time-based freezes
==================

For the squeeze release (and future releases), we are considering a
time-based freeze, meaning that the freeze will happen at a predictable
and predetermined time with the release happening at a later time once
the release requirements are met.  We think that having a time-based
freeze would enhance the responsibility among developers to plan ahead
and make sure that the version they want to get in the next release is
one that is stable and can be well supported. time-based freezes would
make a release schedule more predictable as long as we make sure that
what gets into the freeze is sensible. We do think that a time-based
*release* is a no-go for Debian though, as we only want to release when
we are ready in order to not compromise the quality of the release.

About freeze timing we think that DebConf should definitely not fall
into a freeze and that we should leave time after DebConf to integrate
the possibly disruptive changes we introduced by doing cool stuff at
DebConf. We noticed that releases in the first quarter of the year
worked out quite well in the past like both Etch and Lenny. Taking these
into consideration we think it would be best to freeze in December. As
freezing in December would mean that a release cycle always takes about
the same amount of years, let's consider the various options. Having a
release cycle of 1 year would be very short and would cause some issues
with security support and upgrades. Having a release cycle of 3 years
would be quite long and would mean a very long security support. So it
looks like a release cycle of about 2 years seems the best way to go
forward.



Timeline
========

Based on feedback of the community on the plan to freeze in December
2009 and  the ambituous Release Goals we set for ourselves, we are
revisiting the decision to freeze December 2009.

We'll be consulting all key teams within Debian to see how their plans
and schedules can fit into a new timeline. Before the end of August we
hope to have finished this process of consultation and be able to
present the new plan to you.




Conclusion
==========

So, we're now starting the hard part of the release cycle. Let us enjoy
working together again, and let's prepare to put a high quality and
stable release out of the door again for what Debian is known for.

If you have any feedback or suggestions, please do not hesitate to
contact us on IRC or by mail, please use the debian-devel mailing list
for follow-ups to this email.

[0] http://lists.debian.org/debian-alpha/2009/07/msg00015.html
[1] http://lists.debian.org/debian-hppa/2009/07/msg00083.html