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://rele
ase.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-releaselists.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.d
ebian.org/BSPMarathonLenny
|