From: hertzog Date: Fri, 18 Mar 2011 11:17:01 +0000 (+0000) Subject: Move some sections around X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=developers-reference.git;a=commitdiff_plain;h=98029d6770d85e90e0fe0b454c3ade75ec58910b Move some sections around Include the "Managing RC bugs" and "Coordinate with upstream" in the "Package Maintainer's Duties" section. git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@8578 313b444b-1b9f-4f58-a734-7bb04f332e8d --- diff --git a/developer-duties.dbk b/developer-duties.dbk index a8eb5b1..cf85ffe 100644 --- a/developer-duties.dbk +++ b/developer-duties.dbk @@ -12,6 +12,64 @@ high-quality packages that are well integrated in the system and that adhere to the Debian Policy. +
+Managing release-critical bugs + +Generally you should deal with bug reports on your packages as described in +. However, there's a special category of bugs +that you need to take care of — the so-called release-critical bugs (RC +bugs). All bug reports that have severity critical, +grave or serious are considered to +have an impact on whether the package can be released in the next stable +release of Debian. These bugs can delay the Debian release and/or can justify +the removal of a package at freeze time. That's why these bugs need to be +corrected as quickly as possible. + + +Developers who are part of the Quality +Assurance group are following all such bugs, and trying to help +whenever possible. If, for any reason, you aren't able fix an RC bug in a +package of yours within 2 weeks, you should either ask for help by sending a +mail to the Quality Assurance (QA) group +debian-qa@&lists-host;, or explain your difficulties and +present a plan to fix them by sending a mail to the bug report. Otherwise, +people from the QA group may want to do a Non-Maintainer Upload (see ) after trying to contact you (they might not wait as long as +usual before they do their NMU if they have seen no recent activity from you in +the BTS). + +
+ +
+Coordination with upstream developers + +A big part of your job as Debian maintainer will be to stay in contact with the +upstream developers. Debian users will sometimes report bugs that are not +specific to Debian to our bug tracking system. You have to forward these bug +reports to the upstream developers so that they can be fixed in a future +upstream release. + + +While it's not your job to fix non-Debian specific bugs, you may freely do so +if you're able. When you make such fixes, be sure to pass them on to the +upstream maintainers as well. Debian users and developers will sometimes +submit patches to fix upstream bugs — you should evaluate and forward these +patches upstream. + + +If you need to modify the upstream sources in order to build a policy compliant +package, then you should propose a nice fix to the upstream developers which +can be included there, so that you won't have to modify the sources of the next +upstream version. Whatever changes you need, always try not to fork from the +upstream sources. + + +If you find that the upstream developers are or become hostile towards Debian +or the free software community, you may want to re-consider the need to +include the software in Debian. Sometimes the social cost to the +Debian community is not worth the benefits the software may bring. + +
@@ -144,65 +202,6 @@ yet but where there are people who are interested in applying. -
-Coordination with upstream developers - -A big part of your job as Debian maintainer will be to stay in contact with the -upstream developers. Debian users will sometimes report bugs that are not -specific to Debian to our bug tracking system. You have to forward these bug -reports to the upstream developers so that they can be fixed in a future -upstream release. - - -While it's not your job to fix non-Debian specific bugs, you may freely do so -if you're able. When you make such fixes, be sure to pass them on to the -upstream maintainers as well. Debian users and developers will sometimes -submit patches to fix upstream bugs — you should evaluate and forward these -patches upstream. - - -If you need to modify the upstream sources in order to build a policy compliant -package, then you should propose a nice fix to the upstream developers which -can be included there, so that you won't have to modify the sources of the next -upstream version. Whatever changes you need, always try not to fork from the -upstream sources. - - -If you find that the upstream developers are or become hostile towards Debian -or the free software community, you may want to re-consider the need to -include the software in Debian. Sometimes the social cost to the -Debian community is not worth the benefits the software may bring. - -
- -
-Managing release-critical bugs - -Generally you should deal with bug reports on your packages as described in -. However, there's a special category of bugs -that you need to take care of — the so-called release-critical bugs (RC -bugs). All bug reports that have severity critical, -grave or serious are considered to -have an impact on whether the package can be released in the next stable -release of Debian. These bugs can delay the Debian release and/or can justify -the removal of a package at freeze time. That's why these bugs need to be -corrected as quickly as possible. - - -Developers who are part of the Quality -Assurance group are following all such bugs, and trying to help -whenever possible. If, for any reason, you aren't able fix an RC bug in a -package of yours within 2 weeks, you should either ask for help by sending a -mail to the Quality Assurance (QA) group -debian-qa@&lists-host;, or explain your difficulties and -present a plan to fix them by sending a mail to the bug report. Otherwise, -people from the QA group may want to do a Non-Maintainer Upload (see ) after trying to contact you (they might not wait as long as -usual before they do their NMU if they have seen no recent activity from you in -the BTS). - -
-
Retiring