X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=developers-reference.sgml;h=8917c406994ab45a18f1c255aba891190f5dfa76;hb=3a06b4317d7d02d1c19b0c503561146c5a8e5686;hp=af1aca2b1911645413d314b5c6f7c33ae64bd6ad;hpb=be9ea81016073be70c312fd28af026fd2fa35224;p=developers-reference.git diff --git a/developers-reference.sgml b/developers-reference.sgml index af1aca2..8917c40 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -5,7 +5,7 @@ %commondata; - + @@ -874,18 +874,25 @@ not duplicated. Read the for more information.

Assuming no one else is already working on your prospective package, -you must then submit a short bug () against the -pseudo package wnpp and send a copy to &email-debian-devel; +you must then submit a bug report () against the +pseudo package wnpp describing your plan to create a new package, including, but not limiting yourself to, a description of the package, the license of the prospective package and the current URL where it can be downloaded -from. You should set the subject of the bug to ``ITP: foo +from. +

+You should set the subject of the bug to ``ITP: foo -- short description'', substituting the name of the new -package for foo. The severity of the bug report must be -set to wishlist. Please include a Closes: -bug#nnnnn entry on the changelog of the new package in -order for the bug report to be automatically closed once the new -package is installed on the archive (). +package for foo. The severity of the bug report must be set +to wishlist. If you feel it's necessary, send a copy to +&email-debian-devel; by putting the address in the X-Debbugs-CC: header +of the message (no, don't use CC:, because that way the message's subject +won't indicate the bug number). +

+Please include a Closes: bug#nnnnn entry on the +changelog of the new package in order for the bug report to be +automatically closed once the new package is installed on the archive +().

There are a number of reasons why we ask maintainers to announce their intentions: @@ -1787,11 +1794,16 @@ you should set the package maintainer to Debian QA Group against the pseudo package wnpp. The bug report should be titled O: package -- short description indicating that the package is now orphaned. The severity of the bug -should be set to normal. If the package is especially -crucial to Debian, you should instead submit a bug against -wnpp and title it RFA: package -- short -description and set its severity to important. You -should also email &email-debian-devel; asking for a new maintainer. +should be set to normal. If you feel it's necessary, send a copy +to &email-debian-devel; by putting the address in the X-Debbugs-CC: header +of the message (no, don't use CC:, because that way the message's subject +won't indicate the bug number). +

+If the package is especially crucial to Debian, you should instead submit +a bug against wnpp and title it RFA: package -- +short description and set its severity to +important. Definitely copy the message to debian-devel in this +case, as described above.

Read instructions on the for more information. @@ -1822,7 +1834,6 @@ right away. - Handling Bugs Monitoring bugs @@ -1947,6 +1958,47 @@ that the bug report is not forwarded to the bug distribution mailing list. + + Interaction with Prospective Developers + +

+This chapter describes procedures that existing Debian developers should +follow when it comes to dealing with wannabe developers. + + Sponsoring packages +

+Sponsoring a package means uploading a package for a maintainer who is not +able to do it on their own, a new maintainer applicant. Sponsoring a package +also means accepting responsibility for it. +

+New maintainers usually have certain difficulties creating Debian packages +-- this is quite understandable. That is why the sponsor is there, to check +the package and verify that it is good enough for inclusion in Debian. +(Note that if the sponsored package is new, the FTP admins will also have to +inspect it before letting it in.) +

+Sponsoring merely by signing the upload or just recompiling is +definitely not recommended. You need to build the source +package just like you would build a package of your own. Remember that it +doesn't matter that you left the prospective developer's name both in the +changelog and the control file, the upload can still be traced to you. +

+If you are an application manager for a prospective developer, you can also +be their sponsor. That way you can also verify the how the applicant is +handling the `Tasks and Skills' part of their application. + + Advocating new developers +

+See the page about at the Debian web site. + + Handling new maintainer applications +

+Please see at the Debian web site. + + + Overview of Debian Maintainer Tools

This section contains a rough overview of the tools available to