X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=developers-reference.git;a=blobdiff_plain;f=beyond-pkging.dbk;h=1562f8f6c87f0f1fdff8bbbec052af16032d834b;hp=cafbbd39f0a7f9a9318bee4a7dcceab416fe1f82;hb=b5bd78d4bb84a0450d509fc20ec0df7c34fd040b;hpb=81c0e6409c7dfef4af519821a76dbfadb7dd4758
diff --git a/beyond-pkging.dbk b/beyond-pkging.dbk
index cafbbd3..1562f8f 100644
--- a/beyond-pkging.dbk
+++ b/beyond-pkging.dbk
@@ -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