<!ENTITY % dynamicdata SYSTEM "dynamic.ent" > %dynamicdata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.304 $">
+ <!ENTITY cvs-rev "$Revision: 1.317 $">
<!-- if you are translating this document, please notate the CVS
revision of the original developer's reference in cvs-en-rev -->
<copyright>
<copyrightsummary>
-copyright © 2004—2006 Andreas Barth</copyrightsummary>
+copyright © 2004—2007 Andreas Barth</copyrightsummary>
<copyrightsummary>
copyright © 1998—2003 Adam Di Carlo</copyrightsummary>
<copyrightsummary>
Quality Assurance (QA) work you can join maintainers already working on
these tasks and submit patches and improvements.
+ <p>
+One pitfall could be a too-generic local part in your mailadress:
+Terms like mail, admin, root, master should be avoided, please
+see <url id="http://www.debian.org/MailingLists/"> for details.
+
<sect id="mentors">Debian mentors and sponsors
<p>
<tag><tt>summary</tt>
<item>
-(This is a planned expansion.)
-The regular summary emails about the package's status (bug statistics,
-porting overview, progression in <em>testing</em>, ...).
+Regular summary emails about the package's status.
+Currently, only progression in <em>testing</em> is sent.
+
</taglist>
<p>
"Closes: #nnnnn".
This is useful for the security team to track vulnerabilities.
If an upload is made to fix the bug before the advisory ID is known,
-it is encouraged to modify the historical changelog entry with the next upload;
-please include even in that case all pointers you have to your first
-changelog entry.
+it is encouraged to modify the historical changelog entry with the next upload.
+Even in this case, please include all available pointers to background
+information in the original changelog entry.
<p>
There are a number of reasons why we ask maintainers to announce their
The announcements give maintainers and other interested parties a
better feel of what is going on, and what is new, in the project.
</list>
-
+ <p>
+Please see <url id="http://ftp-master.debian.org/REJECT-FAQ.html">
+for common rejection reasons for a new package.
<sect id="changelog-entries">Recording changes in the package
<p>
<sect1 id="upload-stable">
<heading>Special case: uploads to the <em>stable</em> distribution</heading>
<p>
-Uploading to <em>stable</em> means that the package will be placed into the
-<file>stable-proposed-updates</file> directory of the Debian archive for further
-testing before it is actually included in <em>stable</em>.
+Uploading to <em>stable</em> means that the package will transfered to the
+<em>p-u-new</em>-queue for review by the stable release managers, and
+if approved will be installed in
+<file>stable-proposed-updates</file> directory of the Debian archive.
+From there, it will be included in <em>stable</em> with the next point release.
<p>
Extra care should be taken when uploading to <em>stable</em>. Basically, a
package should only be uploaded to stable if one of the following happens:
those other packages uninstallable, is strongly discouraged.
<p>
The Release Team (which can be reached at &email-debian-release;) will
-regularly evaluate the uploads in <em>stable-proposed-updates</em> and decide if
+regularly evaluate the uploads To <em>stable-proposed-updates</em> and decide if
your package can be included in <em>stable</em>. Please be clear (and
verbose, if necessary) in your changelog entries for uploads to
<em>stable</em>, because otherwise the package won't be considered for
If you need to change the section for one of your packages, change the
package control information to place the package in the desired
section, and re-upload the package (see the <url id="&url-debian-policy;"
-name="Debian Policy Manual"> for details). If your new section is
+name="Debian Policy Manual"> for details).
+You must ensure that you include the <file>.orig.tar.gz</file> in your upload
+(even if you are not uploading a new upstream version),
+or it will not appear in the new section together with the rest of the package.
+If your new section is
valid, it will be moved automatically. If it does not, then contact
the ftpmasters in order to understand what happened.
<p>
removed automatically after the package has been removed from
<em>unstable</em> and no package in <em>testing</em> depends on it.
<p>
-If you are simply restructuring a source package so that it no longer
-produces one or more binary packages, there is no need to explicitly ask
-for the packages that are no longer created to be removed. Such packages
-will be removed when the new package structure has been uploaded into
-<em>unstable</em> and when no package in <em>testing</em> depends on it.
+There is one exception when an explicit removal request is not necessary:
+If a (source or binary) package is an orphan, it will be removed
+semi-automatically.
+For a binary-package, this means if there is no longer any source package
+producing this binary package;
+if the binary package is just no longer produced on some architectures,
+a removal request is still necessary.
+For a source-package, this means that all binary packages it refers to
+have been taken over by another source package.
<p>
-You also have to detail the reasons justifying the request. This is to
+In your removal request, you have to detail the reasons justifying the request.
+This is to
avoid unwanted removals and to keep a trace of why a package has been
removed. For example, you can provide the name of the package that
supersedes the one to be removed.
Other useful programs include
<tt>apt-cache rdepends</tt>,
<prgn>apt-rdepends</prgn> and
-<prgn>grep-dctrl>.
+<prgn>grep-dctrl</prgn>.
Removal of orphaned packages is discussed on &email-debian-qa;.
<p>
Once the package has been removed, the package's bugs should be handled.
Also, after doing an NMU, you have to send
the information to the existing bugs that are fixed by your NMU,
including the unified diff.
-Alternatively you can open a new bug and include a
+Historically, it was custom to open a new bug and include a
patch showing all the changes you have made.
The normal maintainer will either apply the patch or employ an alternate
method of fixing the problem. Sometimes bugs are fixed independently
<sect3>error:
<p>
-<strong>THIS TEMPLATE TYPE IS NOT HANDLED BY DEBCONF YET.</strong>
- <p>
-It has been added to cdebconf, the C version of debconf, first used in
-the Debian Installer.
- <p>
-Please do not use it unless debconf supports it.
- <p>
-This type is designed to handle error message. It is mostly similar to
+This type is designed to handle error messages. It is mostly similar to
the "note" type. Frontends may present it differently (for instance,
the dialog frontend of cdebconf draws a red screen instead of the
usual blue one).
+ <p>
+It is recommended to use this type for any message that needs user
+attention for a correction of any kind.
<sect2>Description: short and extended description
should be kept short for improved readability. Do not mix two ideas
in the same paragraph but rather use another paragraph.
<p>
-Don't be too verbose. Some debconf interfaces cannot deal very well
-with descriptions of more than about 20 lines, so try to keep it below
-this limit.
+Don't be too verbose. User tend to ignore too long screens.
+20 lines are by experience a border you shouldn't cross,
+because that means that in the classical dialog interface,
+people will need to scroll, and lot of people just don't do that.
<p>
For specific rules depending on templates type (string, boolean,
etc.), please read below.
The file should have a name that makes it clear which binary file it
encodes. Usually, some postfix indicating the encoding should be
appended to the original filename.
+Note that you don't need to depend on <package>sharutils</package> to get
+the <prgn>uudecode</prgn> program if you use <prgn>perl</prgn>'s
+<tt>pack</tt> function.
+The code could look like
+<example>
+uuencode-file:
+ perl -ne 'print(pack "u", $$_);' $(file) > $(file).uuencoded
+
+uudecode-file:
+ perl -ne 'print(unpack "u", $$_);' $(file).uuencoded > $(file)
+</example>
</footnote>.
The file would then be decoded and copied to its place during the
build process. Thus the change will be visible quite easy.
will help prevent a situation in which several maintainers start
filing the same bug report simultaneously.
<p>
+Please use the programms <prgn>dd-list</prgn> and
+if appropriate <prgn>whodepends</prgn>
+(from the package devscripts)
+to generate a list of all affected packages, and include the
+output in your mail to &email-debian-devel;.
+ <p>
Note that when sending lots of bugs on the same subject, you should
send the bug report to <email>maintonly@&bugs-host;</email> so
that the bug report is not forwarded to the bug distribution mailing
~ianmdlvl / developers-reference.git / blobdiff