X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=beyond-pkging.dbk;h=88056fcc425d5ac440d48057888cd9eff7d257ec;hb=8334a1a3e21d6fa6e75cd553cb346728f670fad2;hp=b43eda4413c1234c6a4c78c1bc8f20ca6ccc7a6d;hpb=1c245b536e741df8beeceb7c109ccf884cd90276;p=developers-reference.git
diff --git a/beyond-pkging.dbk b/beyond-pkging.dbk
index b43eda4..88056fc 100644
--- a/beyond-pkging.dbk
+++ b/beyond-pkging.dbk
@@ -40,7 +40,7 @@ generally ease the process.
Make sure the bug is not already filed against a package. Each package has a
bug list easily reachable at
-http://&bugs-host;/packagename
+http://&bugs-host;/packagename.
Utilities like querybts
1 can also provide you with this
information (and reportbug will usually invoke
@@ -64,7 +64,7 @@ From time to time you may want to check what has been going on with the bug
reports that you submitted. Take this opportunity to close those that you
can't reproduce anymore. To find out all the bugs you submitted, you just have
to visit
-http://&bugs-host;/from:<your-email-addr>.
+http://&bugs-host;/from:your-email-addr.
Reporting lots of bugs at once (mass bug filing)
@@ -85,7 +85,7 @@ several maintainers start filing the same bug report simultaneously.
Please use the programs dd-list and if appropriate
-whodepends (from the package devscripts) to generate a list
+whodepends (from the package devscripts) to generate a list
of all affected packages, and include the output in your mail to
&email-debian-devel;.
@@ -109,24 +109,24 @@ To add usertags when filing bugs, specify the User and
To: submit@bugs.debian.org
-Subject: <title-of-bug>
+Subject: title-of-bug
-Package: <pkgname>
+Package: pkgname
[ ... ]
-User: <email-addr>
-Usertags: <tag-name> [ <tag-name> ... ]
+User: email-addr
+Usertags: tag-name [ tag-name ... ]
-<description-of-bug ...>
+description-of-bug ...
Note that tags are seperated by spaces and cannot contain underscores. If you
-are filing bugs for for a particular group or team it is recommended that you
+are filing bugs for a particular group or team it is recommended that you
set the User to an appropriate mailing list after describing
your intention there.
To view bugs tagged with a specific usertag, visit
-http://&bugs-host;/cgi-bin/pkgreport.cgi?users=<email-addr>&tag=<tag-name>.
+http://&bugs-host;/cgi-bin/pkgreport.cgi?users=email-addr&tag=tag-name.
@@ -141,13 +141,13 @@ To view bugs tagged with a specific usertag, visit
Even though there is a dedicated group of people for Quality Assurance, QA
duties are not reserved solely for them. You can participate in this effort by
keeping your packages as bug-free as possible, and as lintian-clean (see ) as possible. If you do not find that possible, then you
+linkend="lintian"/>) as possible. If you do not find that possible, then you
should consider orphaning some of your packages (see ). Alternatively, you may ask the help of other people
+linkend="orphaning"/>). Alternatively, you may ask the help of other people
in order to catch up with the backlog of bugs that you have (you can ask for
help on &email-debian-qa; or
&email-debian-devel;). At the same time, you can look for
-co-maintainers (see ).
+co-maintainers (see ).
@@ -197,15 +197,15 @@ version is available and that you need it.
Looking up the email address of the maintainer for the package can be
distracting. Fortunately, there is a simple email alias,
-<package>@&packages-host;, which provides a way to
+package@&packages-host;, which provides a way to
email the maintainer, whatever their individual email address (or addresses)
-may be. Replace <package> with the name of a source
+may be. Replace package with the name of a source
or a binary package.
You may also be interested in contacting the persons who are subscribed to a
-given source package via . You can do so
-by using the <package>@&pts-host; email
+given source package via . You can do so
+by using the package@&pts-host; email
address.
@@ -225,8 +225,8 @@ There is a simple system (the MIA database) in which information about
maintainers who are deemed Missing In Action is recorded. When a member of the
QA group contacts an inactive maintainer or finds more information about one,
this is recorded in the MIA database. This system is available in
-/org/qa.debian.org/mia on the host qa.debian.org
-, and can be queried with the mia-query tool.
+/org/qa.debian.org/mia on the host qa.debian.org,
+and can be queried with the mia-query tool.
Use mia-query --help to see how to query the database.
If you find that no information has been recorded about an inactive maintainer yet,
or that you can add more information, you should generally proceed as follows.
@@ -308,8 +308,8 @@ someone with more time.
If you are interested in working in the MIA team, please have a look at the
-README file in /org/qa.debian.org/mia on
-qa.debian.org where the technical details and the MIA procedures are
+README file in /org/qa.debian.org/mia on
+qa.debian.org where the technical details and the MIA procedures are
documented and contact &email-mia;.
@@ -326,85 +326,233 @@ describes how to help new prospective 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.
+to do it on their own. It's not a trivial matter, the sponsor must verify
+the packaging and ensure that it is of the high level of quality that
+Debian strives to have.
-
-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 ftpmasters will also have to inspect it
-before letting it in.)
+The process of sponsoring a package is:
+
+
+The maintainer prepares a source package (.dsc) and puts it online
+somewhere (like on mentors.debian.net) or even better, provides
+a link to a public VCS repository (see ) where
+the package is maintained.
+
+
+The sponsor downloads (or checkouts) the source package.
+
+
+The sponsor reviews the source package. If she finds issues, she
+informs the maintainer and asks her to provide a fixed version (the
+process starts over at step 1).
+
+
+The sponsor could not find any remaining problem. She builds the
+package, signs it, and uploads it to Debian.
+
+
-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.
+Before delving in the details of how to sponsor a package, you should
+ask yourself whether adding the proposed package is beneficial to Debian.
-If you are an application manager for a prospective developer, you can also be
-their sponsor. That way you can also verify how the applicant is handling the
-'Tasks and Skills' part of their application.
+There's no simple rule to answer this question, it can depend on many
+factors: is the upstream codebase mature and not full of security holes?
+Are there pre-existing packages that can do the same task and how do they
+compare to this new package? Has the new package been requested by users
+and how large is the user base? How active are the upstream developers?
+
+
+You should also ensure that the prospective maintainer is going
+to be a good maintainer. Does she already have some experience with other
+packages? If yes, is she doing a good job with them (check out some bugs)?
+Is she familiar with the package and its programming language?
+Does she have the skills needed for this package? If not, is she able
+to learn them?
-
-
-
-Managing sponsored packages
-By uploading a sponsored package to Debian, you are certifying that the package
-meets minimum Debian standards. That implies that you must build and test the
-package on your own system before uploading.
+It's also a good idea to know where she stands towards Debian: does
+she agree with Debian's philosophy and does she intend to join Debian?
+Given how easy it is to become a Debian Maintainer, you might want
+to only sponsor people who plan to join. That way you know from the start
+that you won't have to act as a sponsor indefinitely.
+
+
+
-
+
Advocating new developers
See the page about at the Debian web site.
-
+
Handling new maintainer applications
Please see Checklist