Sun, 04 Apr 2010
RFH: Release Team
The next Debian release needs help. Releasing Debian is a community effort,
only we together can make it happen.
What needs to be done is mostly one of:
If any of the above lists seem suited to you, but you are missing the
required rights to do so, please don't hesitate to contact us. And if we
notice someone does always the right things, we're keen ourselves to make
sure we don't need touch every request unnecessarily.
- release critical bugs: Anyone can help here. If you are an Debian Developer,
you can upload NMU bug fixes (precondition as always: the bug is already at
least one week old, the fix is long enough in the bug report and the
maintainer didn't disagree). Anyone (including non-Developers) can search
for a proper solution of an RC bug report, or if it's not RC,
downgrade the bug report to important or below. All RC bug reports are
available on http://bts.turmzimmer.net/details.php,
the RC bug policy is available on http://release.debian.org/squeeze/rc_policy.txt.
For "how to NMU", please refer to the Developers Reference.
- bug squashing parties: organise some party in your local Debian
community where you meet with other developers and users and try to crush
as many bugs as possible: by having them fixed, by proposing a patch, by
trying if you could reproduce the bug report.
- release notes: They have been last-minute for all the releases I have
watched so far. If you are interested in getting them done in time (and
this means speaking with lots of different people now, trying things out
yourself etc), that'd be great. There is some work already going on, please
refer to http://lists.debian.org/20100318181919.GA31714@dedibox.ebzao.info
(plus other mails around this one) for all I know about it. Please coordinate
with whoever is already on it (as always).
- release management tools: bts.turmzimmer.net needs to be put on solid
ground. If you are interested, please contact me. (Requires: ability to
read php; ability to write in a sensible language for a webpage, i.e. python
- handling transitions: Some of the transitions waiting to happen could
profit from someone checking if everything is all right. This means finding
out which packages are affected, which of these need sourceful uploads and
coordination with the maintainers of these packages. If it should go to
testing, care needs to be taken to not entangle it with any of the other
ongoing transitions. When all of that is checked and prepared, the
transitioning package can be uploaded and binNMUs be scheduled; appropriate
access to wanna-build could be arranged if you are a Debian
Developer. To avoid many people working on the same transition, please
coordinate with us in the #debian-release IRC channel first.
- finding out why packages didn't migrate to testing: Take a package in
depenency toplist or top stalls from http://release.debian.org/migration/
and check why it didn't migrate. Do or ask for the proper fix (like filing
RC bugs, giving back packages on the buildd, appropriate hints for britney
to let a couple of packages go in together, or whatever is required)
- join the release team: If you have enough time to spare to do most of
the above on a regular basis, consider if you want to join the release
team. If so, please send mail before April 15th to the release mailing list.
Whatever you do: Write about what you achived. Coordinate with others in time. Have fun!