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:
  • 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 and http://lists.debian.org/20100404183801.GB1959@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 or perl)
  • 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.
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.

Whatever you do: Write about what you achived. Coordinate with others in time. Have fun!