This blog should serve both as a reminder of the planned BSPs around the world the upcoming weekends and as a proposal for some tasks to tackle then.
At this point there are two “real-life” BSPs planned for this weekend, 08th-10th September in Vienna (Austria) and Zürich (Switzerland) and another two BSPs planned for the weekend 15th-17th September in Jülich (Germany) and San Cristoba (Venezula).
If you would like to attend one of these parties, you can find additional links regarding these events here.
First a few necessary words on coordination: #debian-bugs on irc.debian.org will be the main channel for overall coordination. Do not hesitate to ask there before tackling any task; there will certainly be people available that can advise against tackling problematic tasks or tasks already worked on, and give general advice.
When working on specific bugs, please claim them or let a DD claim them for you. See also here for list of claims. Tasks that can not be expressed by a claim but are big enough to warrant a notice for others should be noted on http://wiki.debian.org/OngoingBSP or pages linked from there.
There should be plenty of bugs for all levels of complexity, programming language or legal skills and time requirements. So if you never attended to a BSP before and want to help, now is the right time to start.
The RC Bug Squashing HOWTO by Steve Langasek gives a good introduction and is probably a must-read for beginners. But don’t hesitate to ask questions in #debian-bugs, we will be eager to help you to do some work. :)
Non-DDs can also easily contribute by creating patches and/or testing existing ones. Just send them to the related bug report, a DD can easily pick it up from there. See also the end of this mail for a list of useful links.
Procedures: During the BSPs we should use a 0-Day NMU policy again, that means uploads that fix RC bugs that are more than a week old can be uploaded directly. If you feel unsure about a patch and/or if the patch is rather invasive, please consider asking on #debian-bugs for review and/or giving the maintainer some time to react by uploading to the DELAYED queue. If you are unsure whether your package upload might break an ongoing transition, PLEASE speak up on #debian-release and ask for advice there.
Help Etch forward:
- RC-Bugfixing. One way to help is fixing release critical bugs. Here you can find a list of RC bugs affecting Etch.
- Test the installer. d-i beta3 was just released recently and should be tested by many people to help the people working on it judge whether it is a worthy release candidate (they sure hope it is :) See the Debian Installer Website for more information on how to get it, known issues, etc.
- Test Sarge->Etch upgrades. This is particularly useful with "real" systems since you might notice problems that will never occur in more or less clean chroots (hint: there is no one saying you can't use a copy of your real system ;)
- Verify Release Goals. As one of our major release goals is pervasive IPv6 support, all network related applications should be able to work with both, IPv4 and IPv6. If you have the possibility to do so, please test IPv6 integration in all packages you use and report bugs to the BTS or even better, fix them.
- Translate. There are quite a few .pot files out there waiting for you. ;) Debian's l10n website is a good starting point. (If you're new to l10n and/or new to l10n in Debian, try to find someone at your BSP or on IRC to guide you through the first steps. This helps avoid wasted effort and frustration.)
- Fix bugs in orphaned packages. In the list of packages maintained by the QA Group you can find all bugs in orphaned packages, free to be squashed by anyone.
- Fix bugs tagged "help". This this list.
- Fix bugs in your own packages and in packages you often use. Also help on reproducing bugs, if there are unreproducible.
I personally will attend the BSP in Jülich and hope to see many of you during that weekend there or on IRC.