Hi,
after the release is prior to the release. As we all know that, the
Release Team members (except Steve) have met in Juelich recently to
discuss our impressions of the Etch release cycle and kick-off the Lenny
cycle.
Release team structure
~~~~~~~~~~~~~~~~~~~~~~
Steve Langasek, who served as Release Manager for the past two cycles,
doesn't want to be on the hot seat anymore. As he is still an active member
of the release team, we decided to have him titled with "Release Wizard"
now. Luk will become a Release Manager, so that we have again two
Release Managers.
Also, we decided to have the release teams be working even more closely
together. This means that Martin Zobel-Helas, who has helped out quite a
bit in the final leg of the Etch cycle, is now also officially a Release
Assistant, and Luk Claes, who is already working on the Stable Updates for
some time, is now also officially in that role.
Like after Sarge's release, we would like to get now some more people into
the release teams - just wait for a bit of time, we will send out an
explicit call about that rather soon.
Review of the Etch release cycle
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We tried to work out what we liked about the Etch release cycle and
what we felt to be a problem. There are lot of items, so here's the
list:
* Release Goals seemed to work quite well. We want to formalize
this approach a bit for Lenny, see below for more information
about that.
* The linux kernel was a source of some delays for Etch. This was
due to an unexpected high number of (critical) bugs and the
problems around Debian's handling firmware images in the kernel.
To solve this better next time, we want to start looking at the kernel
earlier in the cycle and talking with the kernel team(s) more often.
* The release notes (and upgrade tests) made fewer problems than for
Sarge, but the work on them started too late, which lead to great
pressure on the translators and left only very short time for an actual
review. For Lenny, we want to improve the translation part by using
po4a and again simply start earlier on writing the notes.
* Quality Assurance (QA) checks on the archive were started very late in
the cycle. They were very useful, but the timing was very unfortunate.
We want to encourage all interested parties to start their QA checks as
early as possible and will try to support those by making them a release
goal. Regular rebuilds, upgrade tests for standard configurations and
similiar checks improve Debian's quality!
* The buildds performed a lot better than for Sarge. While the upload
peaks prior to the Sarge freeze completly stucked the build daemons, we
only had very small problems for Etch. Of course, there is still
something left to improve, but we also want to say "Thanks" for the
things that worked quite well.
* Automatic bin-NMUs have been of great use to shorten transitions. As
most packages are now bin-NMUable, we will make further use of this
tool for Lenny.
* Udeb handling in britney still is non-existant. This is a technica
problem that we want to solve for Lenny.
* Version tracking in the BTS was a great improvement relative to Sarge.
For the first time, we could actually see which packages in testing were
buggy and did not need to resort to manual intervention and bug tags. We
want to improve our tools to use the new BTS features (including also
user-tags) to better track the progress of release goals and blockers.
* The number of rc-bugs has been a big problem in the Etch cycle - it got
out of control very early and it took a long time to get down to a
reasonable number before the release. We are seeing the same effect for
Lenny right now, but this time, we want to support an early BSP
marathon to solve those bugs that were filed due to new QA measures.
* 0-day-NMUs and the BSP marathon at the end of the release cycle helped
a lot to bring down the number of bugs, and we will reuse this policy.
* The freeze worked a lot better than for Sarge, both because it was
shorter and there was more manpower to work on unblock requests. We
hope that with even better planning will shorten the freeze time for
Lenny again.
* Final QA on the installation media and pushing them to the mirror
network made less problems than for Sarge, but we are still unhappy
with the time-constraints that make final tests so hard.
Please comment on these issues if you feel that important bits have been
missed, misrepresented or misjudged - and of course the release team only
sees one part of the full picture.
Release policy, blockers and goals
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The release policy on release.debian.org has been mostly the same since
Sarge was released or even before. For Lenny, we want to work on the
document a bit to clarify some items and make it more understandable.
For now, we haven't identified any specific things that we want to add
as release blockers. This might change in the near future, but the list
of blockers needs to be frozen soon.
As said above, we were happy with the success we had with release goals.
For Lenny, we want to make using release goals even easier and better.
Again, what are release goals:
* 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.
* Also most of "our" tools can handle release goals, e.g. they can be show
on bts.turmzimmer.net.
To get a bit better overview, we decided to make a canonical list of
Release Goals. For better structure, and to ease our all work, 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 occurences of
this issue.
If these conditions are fullfilled, 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.
In case the release goal is confirmed, the release team will add the
release goal to the canonical list (which is for now located on
http://release.debian.org/lenny-goals.txt), and tell the developers the tag
name. Please mark any bugs (whether already filed or not) with
goal-$tagname (e.g. goal-debmake) for the user
debian-release@lists.debian.org.
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.
Communication with core teams and the project
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To give all people involved a better overview, we want to send out
release updates more regularly. We also want to include feedback of the core
teams in these release updates. For that, we want to do monthly (or
bimonthly) IRC meetings with the bigger maintainer teams. These meetings
are not supposed to take long and don't need all involved people to
attend, but should make it possible to discuss bigger transitions,
complicated (release-related) bugs or schedule changes before they become
an actual problem.
All of these meetings should happen in the last week of each months, we
will try to summarize the information and then send out a release update
at the beginning of each month.
To make this more efficient, we have agreed to distribute the teams over
the members of the release team. For now, Gnome and XFCE are handled by
Marc, KDE by Adeodato and Marc, X.Org by Luk, Mozilla by Luk and Martin, Tex
by Martin, Python and the Toolchain by Andi and the Kernel and PHP will
be handled by Steve. There are probably more teams we should add there, so
please don't hesitate to contact us.
Britney
~~~~~~~
There are a few things we want to have changed in the testing migration
script:
- Better handling of udebs: Frans Pop proposed some good ideas in May,
which we basically want to have implemented.
- Version tracking: Britney should learn version tracking. This also
provides us with the possibility to consider new bugs more serious than
old ones (for the two simple reasons that a bug just noticed after
transition is usually not "as bad" as one noticed during the first 10
days, and also users had learned a workaround around the "old" bug
mostly).
OK, now on to the juicy bits you actually care about:
Architecture (re)qualification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We will basically continue to use the same criteria for architecture
qualification that were in use for Etch. Some small changes include that we
really want to send out the architecture status at least every second
month. Of course, we need to recheck the criteria soon - but that's left
for a later occasion. Two new criteria were split of the existing criteria:
We split "RM concerns" into "RM concerns" and "SRM concerns", and we split
of from "buildd redundancy" "fast security buildds". Nothing too exciting
anyway.
We also discussed some specific archs:
* As far as we understood, arm is going to die soon, being replaced by
armeb and/or armel. We would like to hear some comments from the porters
about this before deciding if arm should even still be released with
Lenny. If it is really going to die soonish, but is still in regular
use, one option would be to release it with Lenny, but without a
debian-installer, so that new installations are forced to the newer
armeb, and purge arm after release of Lenny. But that is just a
proposal to start off the discussion.
* kfreebsd-{i386,amd64} has seen some improvement in the last year and
looks like it could be ready in time for Lenny. As with the other
architectures, we would like some statements from the porters to better
understand which of the release criteria could still be a problem.
* hurd-i386 has been on ftp.debian.org for some time, but isn't in a
releasable state yet.
As we understand that archive and release qualification is often a problem,
Andi, Martin and Marc (HE) want to provide a new service:
doorstep.debian.net will be installed on a machine in the next few weeks
and will provide a normal dak installation and a wanna-build database, so
that packages can be autobuilt. Source packages will be kept in sync with
the main archive. We will also set up britney instance to allow for a
testing suite in that archive. This service is intended to be used as a
test environment so that architectures can show their maturity before being
added to ftp.debian.org.
Release schedule
~~~~~~~~~~~~~~~~
Probably the most interesting thing in this mail is the schedule we have
discussed for Lenny. After looking at the (known) release dates for some
of the major software packages, we have decided to release Lenny in the
second half of 2008, probably early September 2008. We have discussed a bit
how we could improve situation for Desktop. The only thing we can really
announce as of now is that we want to add a new kernel to Etch halfway (as
was already announced), the rest needs some proper thinking and discussion.
Now on to the draft of the timeline:
August 2007
Start of the first BSP marathon for Lenny, lasting till November. [1]
Early September 2007
The list of release blockers for Lenny is frozen.
Early March 2008
Very soft freeze: Please be extra careful with new versions, and new
transitions. At this point, the list of release goals is frozen.
Start of the second BSP marathon for Lenny.
Early April 2008
Freze of the essential toolchain.
Mid of June 2008
Freeze of the non-essential toolchain and all libraries.
Mid of July 2008
Full freeze.
Early September 2008
Release!
Of course, "Early September" is only an internal goal as of now, the
official communications is "in the second half of 2008".
Cheers,
Andi
--
http://release.debian.org
Debian Release Team
[1] http://wiki.debian.org/BSPMarathonLenny
Attachment:
signature.asc
Description: Digital signature