<!-- common, language independant entities -->
<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.37 $">
+ <!entity cvs-rev "$Revision: 1.38 $">
<!-- if you are translating this document, please notate the RCS
revision of the developers reference here -->
post to that list and an experienced developer will volunteer to help.
- <chapt id="user-maint">Maintaining Your Debian Information
+ <chapt id="developer-duties">Debian Developer's Duties
+
+ <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
+update your password (this password is propagated to most of the machines
+that are accessible to you), your adress, your country, the latitude and
+longitude from the point where you live, phone and fax numbers, your
+preferred shell, your IRC nickname, your web page and the email that
+you're using as alias for your debian.org email. Most of the information
+is not accessible to the public, for more details about this
+database, please read its online documentation that you can find
+here : <url id="&url-debian-db-doc;">.
+ <p>
+You have to keep the information available there up to date.
<sect id="key-maint">Maintaining Your Public Key
<p>
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
+ <p>
+Most of the developers take vacation, usually this means that they can't
+work for Debian and they can't be reached by email if any problem occurs.
+The other developers need to know that you're on vacation so that they'll
+do whatever is needed when such a problem occurs. Usually this means that
+other developers are allowed to NMU your package if a big problem (release
+critical bugs, security update, ...) occurs while you're on vacation.
+ <p>
+In order to inform the other developers, there's two things that you should do.
+First send a mail to &email-debian-private; giving the period of time when
+you will be on vacation, you can also give some special instructions on what to
+do if any problem occurs. Next you should update your information
+available in the Debian LDAP database and mark yourself as « on vacation »
+(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
+ <p>
+A big part of your job as Debian maintainer will be to stay in contact
+with the upstream developers since you'll have to share information that
+you get from the Bug Tracking System. It's not your job to fix non-Debian
+specific bugs so you have to forward the bugs to the upstream developers
+(of course, if you are able to fix them, you can ...). This way the bug
+may be corrected when the next upstream version comes out. From time to
+time, you may get a patch attached to a bug report, you have to send the
+patch upstream and make sure that it gets included (if the authors accept
+the proposed fix). If you need to modify the upstream sources in order to
+build a policy conformant package, then you should propose a nice fix
+to the upstream developers which can be included so that you won't have to
+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
+ <p>
+Release Critical Bugs (RCB) are the bugs of severity « critical »,
+« grave » and « important ». Those bugs can delay
+the Debian release and/or can justify the removal of a package at freeze
+time. That's why those bugs needs to be corrected as fast as possible.
+You must be aware that some developers who are part of the <url
+id="&url-debian-qa;" name="Debian Quality Assurance"> effort are following
+those bugs and try to help you each time they can. But if you can't
+fix such bugs within 2 weeks, you should either ask for help by sending a
+mail to the Quality Assurance (QA) group (&email-debian-qa;) or
+justify yourself and gives your plan to fix it by sending a mail to the
+concerned bug report. Otherwise people from the QA group may want to do a
+Non Maintainer Upload (NMU) after trying to contact you (they might wait
+not as long as usually before they do their NMU if they have seen no
+recent activity from you on the BTS).
+
+ <sect id="qa-effort">Quality Assurance Effort
+ <p>
+Even if there is a dedicated group of people for Quality Assurance, QA is
+not reserved to them. You can participate to this effort by keeping your
+packages as bug free as possible, as lintian-clean (see <ref
+id="lintian-reports">) as possible. If you think that it's quite impossible,
+then you should consider orphaning (see <ref id="orphaning">) some of your
+packages so that you can do a good job with the other packages that you
+maintain. Alternatively you may ask the help of other people in order to
+catch up the backlog of bugs that you have (you can ask for help on
+&email-debian-qa; or &email-debian-devel;).
<sect>Retiring Gracefully
<p>
&email-debian-private; unless it is really necessary. Moreover, do
<em>not</em> forward email from that list to anyone.
<p>
+&email-debian-email; is a special mailing list used as a grab-bag
+for Debian related correspondence such as contacting upstream authors
+about licenses, bugs, etc. or discussing the project with others where it
+might be useful to have the discussion archived somewhere.
+ <p>
As ever on the net, please trim down the quoting of articles you're
replying to. In general, please adhere to the usual conventions for
posting messages.
<tt>Distribution</tt> field. Or, if Debian has been frozen, and you
want to get a bug-fix release into <em>frozen</em>, you would set the
distribution to `frozen unstable'. (See <ref id="upload-frozen"> for
-more information on when to upload to <em>frozen</em>.) Note that
-setting the distribution to `stable' means that the package will be
-placed into the <tt>proposed-updates</tt> directory of the Debian
-archive for further testing before it is actually included in
-<em>stable</em>. Also note that it never makes sense to combine the
-<em>experimental</em> distribution with anything else.
+more information on when to upload to <em>frozen</em>.) Note that it
+never makes sense to combine the <em>experimental</em> distribution with
+anything else. Also note that setting the distribution to `stable' means
+that the package will be placed into the <tt>proposed-updates</tt>
+directory of the Debian archive for further testing before it is actually
+included in <em>stable</em>. The Release Team (which can be reached at
+&email-debian-release;) will decide if your package can be included in
+stable, therefore if your changelog entry is not clear enough, you may
+want to explain them why you uploaded your package to stable by sending
+them a short explication.
<p>
The first time a version is uploaded which corresponds to a particular
upstream version the original source tar file should be uploaded and
<tt>chiark</tt>, and <tt>erlangen</tt>. It can also be configured to
use <prgn>ssh</prgn>. See <manref name="dupload" section="1"> and
<manref name="dupload" section="5"> for more information.
-
+ <p>
+After uploading your package, you can check how dinstall will
+process it by running dinstall on your changes file:
+<example>~maor/dinstall/dinstall -n foo.changes</example>
<sect1 id="upload-non-us">Uploading to <tt>pandora</tt> (non-us)
<p>
The program <prgn>dupload</prgn> comes with support for uploading to
<tt>pandora</tt>; please refer to the documentation that comes with
the program for details.
-
+ <p>
+Just as for an upload to master, you can check your upload with :
+<example>/org/non-us.debian.org/scripts/dinstall/dinstall -n foo.changes
+</example>
+
<sect1>Uploads via <tt>chiark</tt>
<p>
If you have a slow network connection to <tt>master</tt>, there are
<sect id="upload-announce">Announcing package uploads
<p>
When a package is uploaded an announcement should be posted to one of
-the ``debian-changes'' lists. The announcement should give the
-(source) package name and version number, and a very short summary of
-the changes, in the <em>Subject</em> field, and should contain the
-PGP-signed <tt>.changes</tt> file. Some additional explanatory text
-may be added before the start of the <tt>.changes</tt> file.
+the ``debian-changes'' lists. This is now done automatically by dinstall
+when it runs (usually once a day), you just need to use a recent
+<package>dpkg-dev</package> (>= 1.4.1.2). Before that,
+<prgn>dupload</prgn> was used to send those announcements, please make
+sure that you configured your <prgn>dupload</prgn> to no more send those
+announcements (check its documentation and look for dinstall_runs). The
+mail generated by dinstall will contain the PGP/GPG signed .changes files
+that you uploaded with your package.
<p>
If a package is released with the <tt>Distribution:</tt> set to
`stable', the announcement is sent to &email-debian-changes;. If a
package is released with <tt>Distribution:</tt> set to `unstable',
-`experimental', or `frozen' (when present), the announcement should be
+`experimental', or `frozen' (when present), the announcement will be
posted to &email-debian-devel-changes; instead.
<p>
On occasion, it is necessary to upload a package to both the
<em>stable</em> and <em>unstable</em> distributions; this is done by
putting both distributions in the <tt>Distribution:</tt> line. In
-such a case the upload announcement should go to both of the above
+such a case the upload announcement will go to both of the above
mailing lists.
<p>
The <prgn>dupload</prgn> program is clever enough to determine for itself
~ianmdlvl / developers-reference.git / blobdiff