a few more strong words about sponsoring

git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@1215 313b444b-1b9f-4f58-a734-7bb04f332e8d

diff --git a/developers-reference.sgml b/developers-reference.sgml
index 45dcc2202c0d0a02c85e21d855065e4d4a101ce8..a81d9ee01943a074bbbcac8bb288c19ec2a159e9 100644 (file)
--- a/developers-reference.sgml
+++ b/developers-reference.sgml
@@ -5,7 +5,7 @@
   <!-- common, language independant entities -->
   <!entity % commondata  SYSTEM "common.ent" > %commondata;
   <!-- CVS revision of this document -->
-  <!entity cvs-rev "$Revision: 1.60 $">
+  <!entity cvs-rev "$Revision: 1.61 $">
 
   <!-- if you are translating this document, please notate the RCS
        revision of the developers reference here -->
@@ -1977,6 +1977,12 @@ 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.)
        <p>
+Sponsoring merely by signing the upload or just recompiling is
+<strong>definitely not recommended</strong>. 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.
+       <p>
 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.