X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=beyond-pkging.dbk;h=25987fed41c857998ac0f92207fa3a9b1aff4ffc;hb=de9303fd6b9183e5b1cfbce5fccc68ab9f968cde;hp=0d27668977c723d4f15da1cf50964b05fa1f119b;hpb=a52b7e8c084a73282543e5e870ae8c68ed2abcb1;p=developers-reference.git
diff --git a/beyond-pkging.dbk b/beyond-pkging.dbk
index 0d27668..25987fe 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
+https://&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>.
+https://&bugs-host;/from:your-email-addr.
Reporting lots of bugs at once (mass bug filing)
@@ -84,8 +84,8 @@ is a real problem. In addition, it will help prevent a situation in which
several maintainers start filing the same bug report simultaneously.
-Please use the programms dd-list and if appropriate
-whodepends (from the package devscripts) to generate a list
+Please use the programs dd-list and if appropriate
+whodepends (from the package devscripts) to generate a list
of all affected packages, and include the output in your mail to
&email-debian-devel;.
@@ -94,6 +94,41 @@ Note that when sending lots of bugs on the same subject, you should send the
bug report to maintonly@&bugs-host; so that the bug report
is not forwarded to the bug distribution mailing list.
+
@@ -106,13 +141,13 @@ is not forwarded to the bug distribution mailing list.
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 ).
@@ -124,8 +159,8 @@ many problems as possible. They are announced on
&email-debian-devel-announce; and the announcement explains
which area will be the focus of the party: usually they focus on release
critical bugs but it may happen that they decide to help finish a major upgrade
-(like a new perl version which requires recompilation of all the binary
-modules).
+(like a new perl version which requires recompilation of all
+the binary modules).
The rules for non-maintainer uploads differ during the parties because the
@@ -162,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.
@@ -190,11 +225,11 @@ 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 a
-tool known as mia-query. 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.
+/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.
The first step is to politely contact the maintainer, and wait a reasonable
@@ -211,11 +246,12 @@ maintainer in question as possible. This includes:
-The echelon information available through the echelon information available through the developers' LDAP database, which indicates
when the developer last posted to a Debian mailing list. (This includes
-uploads via debian-*-changes lists.) Also, remember to check whether the
-maintainer is marked as on vacation in the database.
+mails about uploads distributed via the &email-debian-devel-changes; list.)
+Also, remember to check whether the maintainer is marked as on vacation in
+the database.
@@ -237,11 +273,11 @@ groups.
A bit of a problem are packages which were sponsored â the maintainer is not
-an official Debian developer. The echelon information is not available for
-sponsored people, for example, so you need to find and contact the Debian
-developer who has actually uploaded the package. Given that they signed the
-package, they're responsible for the upload anyhow, and are likely to know what
-happened to the person they sponsored.
+an official Debian developer. The echelon information is not
+available for sponsored people, for example, so you need to find and contact the
+Debian developer who has actually uploaded the package. Given that they signed
+the package, they're responsible for the upload anyhow, and are likely to know
+what happened to the person they sponsored.
It is also allowed to post a query to &email-debian-devel;,
@@ -272,9 +308,9 @@ 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 documented and contact
-&email-mia;.
+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;.
@@ -290,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 they find issues, they
+inform the maintainer and ask them to provide a fixed version (the
+process starts over at step 1).
+
+
+The sponsor could not find any remaining problem. They build the
+package, sign it, and upload 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. Do they already have some experience with other
+packages? If yes, are they doing a good job with them (check out some bugs)?
+Are they familiar with the package and its programming language?
+Do they have the skills needed for this package? If not, are they 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 they stand with respect to Debian: do
+they agree with Debian's philosophy and do they 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