<!-- common, language independant entities -->
<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.90 $">
+ <!entity cvs-rev "$Revision: 1.91 $">
<!-- if you are translating this document, please notate the RCS
revision of the developers reference here -->
a lot of timer later on.
- <sect id="mentors">Debian Mentors and Sponsors
+ <sect id="mentors">Debian mentors and sponsors
<p>
The mailing list &email-debian-mentors; has been set up for novice
maintainers who seek help with initial packaging and other
are people who are official Debian maintainers, and who are willing to
critique and upload your packages for you. Sponsorees can request a
sponsors at <url id="&url-sponsors;">.
+ <p>
+If you wish to be a mentor and/or sponsor, more information is
+available in <ref id="newmaint">.
<chapt id="developer-duties">Debian Developer's Duties
- <sect id="user-maint">Maintaining Your Debian Information
+ <sect id="user-maint">Maintaining your Debian information
<p>
There's a LDAP database containing many informations concerning all
developers, you can access it at <url id="&url-debian-db;">. You can
You can find a more in-depth discussion of Debian key maintenance in
the documentation for the <package>debian-keyring</package> package.
- <sect id="inform-vacation">Going On Vacation Gracefully
+ <sect id="inform-vacation">Going on vacation gracefully
<p>
Most developers take vacations, and usually this means that they can't
work for Debian and they can't be reached by email if any problem occurs.
(this information is only accessible to debian developers). Don't forget
to remove the ``on vacation'' flag when you come back!
- <sect id="upstream-coordination">Coordination With Upstream Developers
+ <sect id="upstream-coordination">Coordination With upstream developers
<p>
A big part of your job as Debian maintainer will be to stay in contact
with the upstream developers. Debian users will sometimes report bugs
modify the sources of the next upstream version. Whatever changes you
need, always try not to fork from the upstream sources.
- <sect id="rc-bugs">Managing Release Critical Bugs
+ <sect id="rc-bugs">Managing release-critical bugs
<p>
-Release Critical Bugs (RCB) are all bugs that have severity
+Release-critical bugs (RCB) are all bugs that have severity
<em>critical</em>, <em>grave</em> or <em>serious</em>.
Those bugs can delay the Debian release
and/or can justify the removal of a package at freeze time. That's why
usual before they do their NMU if they have seen no recent activity from you
in the BTS).
- <sect id="qa-effort">Quality Assurance Effort
+ <sect id="qa-effort">Quality Assurance effort
<p>
Even though there is a dedicated group of people for Quality
Assurance, QA duties are not reserved solely for them. You can
Send all this information to &email-debian-qa;, in order to let the
QA people do whatever is needed.
- <sect>Retiring Gracefully
+ <sect>Retiring
<p>
If you choose to leave the Debian project, you should make sure you do
the following steps:
</enumlist>
+ <chapt>
+ <heading>Beyond Packaging</heading>
+ <p>
+Debian is about a lot more than just packaging software and
+maintaining those packages. This chapter contains information about
+ways, often really critical ways, to contribute to Debian beyond the
+simply creating and maintaining packages.
+ <p>
+As a volunteer organization, Debian relies on the discretion of its
+members in choosing what they want to work on, and choosing what is
+the most critical thing to spend their time on.
+
+
+ <sect id="newmaint">
+ <heading>Interacting with prospective Debian developers</heading>
+ <p>
+Debian's success depends on it's ability to attract and retain new and
+talented volunteers. If you are an experienced developer, we
+recommend that you get involved with the process of brining in new
+developers. This section describes how to help new prospective
+developers.
+
+
+ <sect1 id="sponsoring">Sponsoring packages
+ <p>
+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.
+ <p>
+If you wish to volunteer as a sponsor, you can sign up at <url
+id="&url-sponsors;">.
+ <p>
+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.)
+ <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.
+
+
+ <sect1>Advocating new developers
+ <p>
+See the page about <url id="&url-newmaint-advocate;"
+name="advocating a prospective developer"> at the Debian web site.
+
+ <sect1>Handling new maintainer applications
+ <p>
+Please see <url id="&url-newmaint-amchecklist;" name="Checklist for
+Application Managers"> at the Debian web site.
+
+
+
+
<chapt id="servers">Mailing Lists, Servers, and Other Machines
<p>
In this chapter you will find a very brief road map of the Debian
have accounts on these machines.
- <sect id="other-machines">Other Debian Machines
+ <sect id="other-machines">Other Debian machines
<p>
There are other Debian machines which may be made available to you.
You can use these for Debian-related purposes as you see fit. Please
the program for details.
- <sect1>Other Upload Queues
+ <sect1>Other upload queues
<p>
Another upload queue is available which is based in the US, and is a
good backup when there are problems reaching <tt>ftp-master</tt>. You can
&number-of-arches; more builds.
- <sect id="kind-to-porters">Being Kind to Porters
+ <sect id="kind-to-porters">Being kind to porters
<p>
Porters have a difficult and unique task, since they are required to
deal with a large volume of packages. Ideally, every source package
architectures sometimes standardize on different compilers.
<item>
Make sure your debian/rules contains separate ``binary-arch'' and
-``binary-indep'' targets, as the Debian Packaging Manual requires.
+``binary-indep'' targets, as the Debian Policy Manual requires.
Make sure that both targets work independently, that is, that you can
call the target without having called the other before. To test this,
try to run <tt>dpkg-buildpackage -b</tt>.
</enumlist>
- <sect id="porter-guidelines">Guidelines for Porter Uploads
+ <sect id="porter-guidelines">Guidelines for porter uploads
<p>
If the package builds out of the box for the architecture to be ported
to, you are in luck and your job is easy. This section applies to
package, using the `binary-arch' target in <file>debian/rules</file>.
<sect1 id="recompile-nmu-versioning">
- <heading>Recompilation Binary-Only NMU Versioning</heading>
+ <heading>Recompilation binary-only NMU versioning</heading>
<p>
Sometimes you need to recompile a package against other packages which
have been updated, such as libraries. You do have to bump the version
blessing or status, so buyer, beware.
- <sect>Tools for Porters
+ <sect>Tools for porters
<p>
There are several tools available for the porting effort. This section
contains a brief introduction to these tools; see the package
Replace <var>address</var> with you official Debian
maintainer address.
- <sect id="submit-bug">Submitting Bugs
+ <sect id="submit-bug">Submitting bugs
<p>
Often as a package maintainer, you find bugs in other packages or else
have bugs reported to your packages which need to be reassigned. The
not actually close the bug (unless you secure permission from the
maintainer).
- <sect>Responding to Bugs
+ <sect>Responding to bugs
<p>
Make sure that any discussions you have about bugs are sent both to
the original submitter of the bug, and the bug itself (e.g.,
list.
- <chapt id="newmaint">
- <heading>Interaction with Prospective Developers</heading>
-
- <p>
-This chapter describes procedures that existing Debian developers should
-follow when it comes to dealing with wannabe developers.
-
- <sect id="sponsoring">Sponsoring packages
- <p>
-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.
- <p>
-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.)
- <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.
-
- <sect>Advocating new developers
- <p>
-See the page about <url id="&url-newmaint-advocate;"
-name="advocating a prospective developer"> at the Debian web site.
-
- <sect>Handling new maintainer applications
- <p>
-Please see <url id="&url-newmaint-amchecklist;" name="Checklist for
-Application Managers"> at the Debian web site.
-
-
<chapt id="tools">Overview of Debian Maintainer Tools
<p>