Hi,
Happy New Year to all of you. New Year in the western world is the typical
point in time to take a look backward and forward to see what happened and
what one expects to happen next year. Also, we're almost in the middle
between release of sarge and release of etch, another good reason to look
both ways. :)
We have sent out many release updates during the first months of last year,
until we released sarge r0 on 6th of June.
More or less at the same time, we published a proposed set of guidelines
for the architectures for the next stable release etch. After some hard
discussion, we managed to get a list that was agreed on by most of Debian's
developers.[1] The re-qualifications of architectures has happened by
now[2], the architectures that didn't qualify have chances to re-qualify
every two months. For the release team, this whole discussion helped
already a lot, because it makes more obvious who is responsible for what,
and it helped to weed out easy resolvable issues that are bad for the
release of etch.
Now, let's look forward what we expect to see in 2006: We expect to release
etch as planned in beginning of December 2006.[3]
Our time line still is:
N-117 = Mon 30 Jul 06: freeze essential toolchain, kernels
N-110 = Mon 7 Aug 06: freeze base, non-essential toolchain (including
e.g. cdbs)
N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze]
N-45 = Wed 18 Oct 06: general freeze [about 2 months after base
freeze, d-i RC]
N = Mon 4 Dec 06: release [1.5 months for the general freeze]
The good news is that we are on track to reach this goal.
However, we need to start *now* to give the RC-bug count some more
attention. This means also that we're going to start again an everlasting
BSP: For RC-bugs, you can upload 0-days NMUs for RC-bugs open for more
than one week. However, you are still required to notify the maintainer
via BTS before uploading. And of course, you need to take care of
anything you broke by your NMU.
Also it is critical that NMU patches to source should be as non-disruptive
as possible. Do not do housekeeping tasks, do not change the name of
modules or files, do not move directories; in general, do not fix things
which are not broken. Keep the patch as small as possible. If things bother
you aesthetically, talk to the Debian maintainer, talk to the upstream
maintainer, or submit a bug. However, aesthetic changes must not be made in
a non-maintainer upload.
And please remember the Hippocratic Oath: "Above all, do no harm." It is
better to leave a package with an open grave bug than applying a
non-functional patch, or one that hides the bug instead of resolving it.
Please see the developers reference for more details [4], and expect another
mail soon that tells more about NMU rules.
Looking at the installer, there has been huge progress. Also, a new d-i RC
has already been published. We definitely trust the installer team to be
ready in time.
There have been some changes to our toolchain, and the toolchain seems to
be quite stable by now. There are still some discussions about integration
of e.g. multiarch, but it is almost too late for it right now.
Looking at our release targets published back in October[3], we had:
- gcc 3.3 -> 4.0 toolchain transition
- xfree86 -> xorg transition
these two are done
- amd64 as an official arch (and the mirror split as a pre-condition
for that)
this still needs to happen
- sorting out docs-in-main vs. the DFSG
has happened partially - our biggest issue is still the GFDL-situation. If
we look at our release planning, we need to start aggressively removing
GFDL-only-documentation beginning of March, unless the license issues are
resolved before.
- sorting out non-free firmware
also some work needs to be done here - or did changes in upstream resolve
that mostly for us?
- secure apt
secure apt is now part of testing. However, we need to do something for key
management etc - so some small issues need to be resolved.
So much for now. We wish you a Happy New Year, and let's release etch
together beginning of December 06.
Cheers,
--
Andi
Debian Release Team
[1] http://release.debian.org/etch_arch_policy.html
[2] http://lists.debian.org/debian-devel-announce/2005/12/msg00013.html
[3] http://lists.debian.org/debian-devel-announce/2005/10/msg00004.html
[4] http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu
Attachment:
signature.asc
Description: Digital signature