Re: Invite to join the Release Team
On Fri, Mar 19, 2010 at 02:57:51PM +0100, Marc 'HE' Brockschmidt wrote:
> Yes, please!
If you don't care about Debian 6.0 (codename "squeeze"),
please skip this release update.
Andreas Barth would like to sy that we have recently
discussed the situation of the release, and it looks
like we can pull the release off if we all do it
together. As you know, releasing Debian is a team effort.
Please see below the status of the open issues. If there is
anything that you think needs to be part of high-level
release planning and is not included below, please bring it
to the release teams attention as soon as possible.
== Current Transitions ==
Many transitions are currently in progress.
The imagemagick transition has just been completed.
The liblo transition is hanging on sivp.
There are still plenty of open bugs relevant to the python2.6
transition. In addition, python-central needs to be fixed before
a slew of binNMUs can be scheduled.
Switching mpi-defaults could break at least the following
packages: apbs blacs-mpi gdcm igstk kwwidgets mumps petsc
pgapack rmpi scalapack
parted 2.2 moving from experimental to unstable will affect
the following packages: devicekit-disks fatresize gnu-fdisk
gparted libvirt partconf partitioner partitionmanager
partman-base pyparted qtparted udisks
eglibc 2.11 is being held up by serious hppa NPTL breakage,
and if you are interested in all the great new features and
performance enhancements, you might want to assist the hppa
porters. The sooner eglibc 2.11 can get into unstable, the
sooner any related bugs can be detected. Lucas Nussbaum has
done an archive rebuild with eglibc 2.11, and few issues
were found, but there is no substitute for the thorough
testing that comes through dogfooding.
The linux-2.6/linux-base libata transition is ongoing in sid
for i386 and will soon affect all architecture.
Other transitions include BLAS/LAPACK and ruby1.9.1, which are
presenting complexity or difficulties, as well as directfb,
icu, boost 1.42, qt4.6, KDE 4.4, GNOME 2.30, icedove3, and
The number of RC bugs concerning squeeze is currently 756.
Since the target for release is 0 RC bugs, this means a lot
of bugs need to be fixed, and some packages removed from testing.
Removals are more likely to occur if maintainers are unresponsive,
but to get a removed package back into testing can be as trivial as
fixing the RC bugs and waiting.
== Release Goals ==
Many release goals may not be achieved in time. Full IPv6
support is at least 115 bugs away from fruition. On the
other hand, the Large File Support goal seems to be only
10 bugs away.
Having all packages be compatible with a potential dpkg-source
default source format change is 81 bugs away. These are
very easy bugs to fix; if you find the 3.0 formats too confusing
or scary, you can simply add a 1-line debian/source/format to
make everyone happy and close the bug.
Removing all unneeded .la files is also very far off.
GRUB2 is the default for some new installations, but not all
cases. The downfall of OSS is only 3 bugs away.
The two GNU/kFreeBSD architectures in the archive are at
risk due to insufficient archive coverage.
Open bugs still remain in the way of the "Boot
Performance" release goal.
MultiArch is still lacking dpkg support, and it looks
like it would take a herculean effort to achieve everything
Many packages still use obsolete GNOME libraries.
== Timeline ==
We anticipate 7-10 days to finish transitioning at least
liblo. The python2.6 switch could take two to four weeks,
assuming no unpleasant surprises. This will involve a
large binNMU campaign (about 200 packages) in addition to
sourceful uploads. directfb and icu transitions could be
done simultaneously, and then followed by boost, qt4.6,
and KDE 4.4.
If the python2.6 switch, directfb, and icu transitions can
be completed by the end of April, and sufficient effort is
put into QA and release work, a freeze by the end of May
is not out of the question.
== How to Help ==
Since there is an enormous amount of RC bugs, you can help
facilitate the release by fixing RC bugs in your own packages.
Other people might lack the time or motivation to live up to
their responsibilities, so you can also fix the bugs in
other people's packages.
You might want to only upload software that you believe to
be stable; packaging a version that you expect to get stable
by freeze time could lead to unpleasant surprises and delay
Perhaps you would like to triage RC bugs. Perhaps you would
like to monitor the state of release goals and give
appropriate nudges. Perhaps you would like to help with the
release notes. Perhaps you would like to motivate others
to do any of these things.
== Administrivia ==
At present there is no official Release Manager, and all release
team members are considered to have full authority on all matters.