[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug Squashing Party next weekend (14-16/3)


during the next week-end (14-16 March), we'll have our third bug
squashing party for sarge.  


Libc6 will enter testing this weekend, allowing for a lot of packages to
progress into testing along with it.  This will most probably break
thing that'll have to get fixed.
Apart from this, there are about 800 outstanding Release Critical bugs
that will have to be resolved before we can even think about
releasing Sarge.
If you were unhappy with the long time Woody took to came out, it's a
good idea to help out this week-end.


A bug squashing party is an occasion to correct as many release critical
bugs as possible in all the packages of Debian.  Correcting usually means:
 - submitting patches to the BTS
 - making NMUs


We meet on #debian-bugs on the Freenode (irc.debian.org) IRC network.
There, you can ask any question about the bug squashing party during the

The list of critical bugs is available at

Unfortunately, the http://bugs.debian.net/ pages, where in previous BSPs
was recorded who was working on which bug, is offline and being replaced
by http://bugs.qa.debian.org/. The latter isn't totally functional at
the moment, though.  Therefore, coordination will take place via the
#debian-bugs IRC channel.  To avoid doing double work, be sure to check
there before hacking on any bug.

If you have a fix but you're unable to upload the package because you're
not a Debian developer, you can ask someone on #debian-bugs to do it
for you.  Before that make sure to send the patch to the BTS and to tag
the bug with the "patch" keyword.

Sometimes, release critical bugs do not deserve their release critical
status.  The severity may need to be lowered.  You can do that if you
have a consensus about it on #debian-bugs.


During a BSP, Non Maintainer Upload rules are simplified.  You can
NMU any package without previous notice to the maintainer.  Instead of
uploading the package to incoming directly, you should however upload
it to the DELAYED directory (read developers-reference[1] for more info
about how to do that).  Full patch of the NMU must still be sent to the
BTS for the maintainer.  At the same time, you should inform him of the
time he has before your upload to the DELAYED directory will make its
way into incoming itself.  Also the bug should be tagged "pending" in
the BTS.

The loosened rules don't mean that you should forget common sense.  Don't
NMU a package without a bit of testing.  Don't NMU if you know that the
maintainer is active and will happily include the patch that you will


If you want more information about this BSP, feel free to ask on
debian-qa@lists.debian.org, #debian-devel or #debian-bugs.

[1] http://www.debian.org/doc/manuals/developers-reference/ch-resources.en.html#s-delayed-incoming

Kind regards,
| Bas Zoetekouw              | GPG key: 0644fab7                     |
|----------------------------| Fingerprint: c1f5 f24c d514 3fec 8bf6 |
| bas@o2w.nl, bas@debian.org |              a2b1 2bae e41f 0644 fab7 |

Attachment: pgpoLEOhSk8WG.pgp
Description: PGP signature

Reply to: