<!ENTITY % versiondata SYSTEM "version.ent"> %versiondata;
<!-- common, language independent entities -->
<!ENTITY % commondata SYSTEM "common.ent" > %commondata;
+ <!ENTITY % dynamicdata SYSTEM "dynamic.ent" > %dynamicdata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.246 $">
+ <!ENTITY cvs-rev "$Revision: 1.270 $">
<!-- 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 Andreas Barth</copyrightsummary>
+copyright © 2004—2005 Andreas Barth</copyrightsummary>
<copyrightsummary>
copyright © 1998—2003 Adam Di Carlo</copyrightsummary>
<copyrightsummary>
id="&url-gpl;" name="the GNU web site">. You can also obtain it by
writing to the &fsf-addr;.
+<![ %htmltext [
+ <p>
+If you want to print this reference, you should use the <url
+id="developers-reference.pdf" name="pdf version">.
+This page is also available in <url id="index.fr.html" name="French">.
+]]>
+
<toc detail="sect1">
<chapt id="scope">Scope of This Document
get started. Finally, if you are interested in documentation or
Quality Assurance (QA) work you can join maintainers already working on
these tasks and submit patches and improvements.
+
+
+ <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
+developer-related issues. Every new developer is invited to subscribe
+to that list (see <ref id="mailing-lists"> for details).
+ <p>
+Those who prefer one-on-one help (e.g., via private email) should also
+post to that list and an experienced developer will volunteer to help.
+ <p>
+In addition, if you have some packages ready for inclusion in Debian,
+but are waiting for your new maintainer application to go through, you
+might be able find a sponsor to upload your package for you. Sponsors
+are people who are official Debian maintainers, and who are willing to
+criticize and upload your packages for you.
+<!-- FIXME - out of order
+Those who are seeking a
+sponsor can request one at <url id="&url-sponsors;">.
+-->
+Please read the
+inofficial debian-mentors FAQ at <url id="&url-mentors;"> first.
+ <p>
+If you wish to be a mentor and/or sponsor, more information is
+available in <ref id="newmaint">.
<sect id="registering">Registering as a Debian developer
accounts on our servers and let them upload packages.
<p>
Before you actually register you should have shown that you can do
-competent work and will be a good contributor. You can show this by
-submitting patches through the Bug Tracking System or having a package
+competent work and will be a good contributor.
+You show this by submitting patches through the Bug Tracking System
+and having a package
sponsored by an existing maintainer for a while. Also, we expect that
contributors are interested in the whole project and not just in
maintaining their own packages. If you can help other maintainers by
is not signed yet, you should try to meet a Debian maintainer in
person to get your key signed. There's a <url id="&url-gpg-coord;"
name="GnuPG Key Signing Coordination page"> which should help you find
-a maintainer close to you. (If you cannot find a Debian maintainer
-close to you, there's an alternative way to pass the ID check. You
-can send in a photo ID signed with your GnuPG key. Having your GnuPG
-key signed is the preferred way, however. See the
-<url id="&url-newmaint-id;" name="identification page"> for more
-information about these two options.)
+a maintainer close to you.
+(If there is no Debian maintainer close to you,
+alternative ways to pass the ID check may be permitted
+as an absolute exception on a case-by-case-basis.
+See the <url id="&url-newmaint-id;" name="identification page">
+for more informations.)
<p>
If you do not have an OpenPGP key yet, generate one. Every developer
OpenPGP is an open standard based on <url id="&url-rfc2440;" name="RFC
2440">.
<p>
-<!-- FIXME: DSS is not exactly equivalent to DSA, is it? -->
-The recommended public key algorithm for use in Debian development
-work is DSA (sometimes called ``DSS'' or ``DH/ElGamal'').
-Other key types may be used, however. Your key length must be at least 1024
+You need a type 4 key for use in Debian Development.
+Your key length must be at least 1024
bits; there is no reason to use a smaller key, and doing so would be
-much less secure. Your key must be signed with at least your own user
+much less secure. Your key must be signed with your own user
ID; this prevents user ID tampering. <prgn>gpg</prgn> does this
automatically.
<p>
citizens. This need not impede one's activities as a Debian package
maintainer however, as it may be perfectly legal to use cryptographic
products for authentication, rather than encryption purposes.
-&debian-formal; does not require the use of cryptography <em>qua</em>
-cryptography in any manner. If you live in a country where use of
+If you live in a country where use of
cryptography even for authentication is forbidden
then please contact us so we can make special arrangements.
<p>
a lot of time later on.
- <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
-developer-related issues. Every new developer is invited to subscribe
-to that list (see <ref id="mailing-lists"> for details).
- <p>
-Those who prefer one-on-one help (e.g., via private email) should also
-post to that list and an experienced developer will volunteer to help.
- <p>
-In addition, if you have some packages ready for inclusion in Debian,
-but are waiting for your new maintainer application to go through, you
-might be able find a sponsor to upload your package for you. Sponsors
-are people who are official Debian maintainers, and who are willing to
-criticize and upload your packages for you. Those who are seeking a
-sponsor can request one at <url id="&url-sponsors;">. Please read the
-inofficial debian-mentors FAQ at <url id="&url-mentors;"> first.
- <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
<tt>&keyserver-host;</tt>.
<p>
If you need to add a completely new key or remove an old key, you need
-to get the new key signed by another developer. After this, a mail
-signed by another developer listing your account name, the keyids
-of the old and of the new key and the reason should be send to
-&email-debian-keyring;. If the old key is compromised or invalid, you
+to get the new key signed by another developer.
+If the old key is compromised or invalid, you
also have to add the revocation certificate. If there is no real
-reason for a new key, the Keyring Maintainers will only accept it if
-it's more secure and connected to the old key.
+reason for a new key, the Keyring Maintainers might reject the new key.
+Details can be found at
+<url id="http://keyring.debian.org/replacing_keys.html">.
<p>
The same key extraction routines discussed in <ref id="registering">
apply.
<qref id="devel-db">Debian developers' LDAP database</qref> (this
information is only accessible to Debian developers).
Don't forget to remove the "on vacation" flag when you come back!
+ <p>
+Ideally, you should sign up at the
+<url id="http://nm.debian.org/gpg.php" name="GPG coordination site">
+when booking a holiday and check if anyone there is looking for signing.
+This is especially important when people go to exotic places
+where we don't have any developers yet but
+where there are people who are interested in applying.
<sect id="upstream-coordination">Coordination with upstream developers
<p>
There are other additional channels dedicated to specific subjects.
<em>#debian-bugs</em> is used for coordinating bug squash parties.
-<em>#debian-boot</em> is used to coordinate the work on the boot
-floppies (i.e., the installer).
-<!-- FIXME: is boot-floppies an anachronism, or still the channel name? -->
+<em>#debian-boot</em> is used to coordinate the work on the debian-installer.
<em>#debian-doc</em> is
occasionally used to talk about documentation, like the document you are
reading. Other channels are dedicated to an architecture or a set of
Channels dedicated to Debian also exist on other IRC networks, notably on
the <url name="Open and free technology community (OFTC)"
id="http://www.oftc.net/"> IRC network.
+ <p>
+To get a cloak on freenode, you send Göran Weinholt <weinholt@debian.org>
+a signed mail where you tell what your nick is.
+Put "cloak" somewhere in the Subject: header.
+The nick should be registered:
+<url id="http://freenode.net/faq.shtml#nicksetup" name="Nick Setup Page">.
+The mail needs to be signed by a key in the Debian keyring.
+Please see
+<url id="http://freenode.net/faq.shtml#projectcloak" name="Freenodes documentation">
+for more information about cloaks.
<sect id="doc-rsrcs">Documentation
<sect1 id="servers-non-us">The non-US server
<p>
-The non-US server, <tt>non-us.debian.org</tt>,
-holds the canonical copy of the non-US part of the Debian archive.
-If you need to upload a package into one of the non-US sections, upload it
-to this server; see <ref id="upload-non-us">.
- <p>
-Problems with the non-US package archive should generally be submitted as
-bugs against the <package>nonus.debian.org</package> pseudo-package (notice
-the lack of hyphen between "non" and "us" in the pseudo-package name
-— that's for backwards compatibility). Remember to check whether or
-not someone else has already reported the problem to the
-<url id="http://&bugs-host;/nonus.debian.org" name="Bug Tracking System">.
+The non-US server <tt>non-us.debian.org</tt>
+was discontinued with the release of sarge. The pseudo-package
+<package>nonus.debian.org</package>
+stil exists for now.
<sect1 id="servers-www">The www-master server
<p>
<p>
Usually the only reason to use a different host is when you need to publish
materials subject to the U.S. export restrictions, in which case you can use
-one of the other servers located outside the United States, such as the
-aforementioned <tt>non-us.debian.org</tt>.
+one of the other servers located outside the United States.
<p>
Send mail to &email-debian-devel; if you have any questions.
<sect1 id="servers-cvs">The CVS server
-<!-- TODO: document svn.debian.org also -->
+<!-- TODO: document svn.debian.org, arch.debian.org also -->
<p>
Our CVS server is located on <tt>cvs.debian.org</tt>.
<p>
<p>
On the other hand, a CD-ROM vendor could easily check the individual
package licenses of the packages in <em>non-free</em> and include as
-many on the CD-ROMs as he's allowed to. (Since this varies greatly from
+many on the CD-ROMs as it's allowed to. (Since this varies greatly from
vendor to vendor, this job can't be done by the Debian developers.)
<p>
Note that the term "section" is also used to refer to categories
tightened. Packages which are too buggy are removed. No changes are
allowed into <em>testing</em> except for bug fixes. After some time
has elapsed, depending on progress, the <em>testing</em> distribution
-goes into a `deep freeze', when no changes are made to it except those
-needed for the installation system. This is called a “test cycle”,
-and it can last up to two weeks. There can be several test cycles,
-until the distribution is prepared for release, as decided by the
-release manager. At the end of the last test cycle, the
-<em>testing</em> distribution is renamed to <em>stable</em>,
-overriding the old <em>stable</em> distribution, which is removed at
-that time (although it can be found at <tt>&archive-host;</tt>).
+is frozen even further.
+Details of the handling of the testing distribution are published
+by the Release Team on debian-devel-announce.
+After the open issues are solved to the satisfaction of the Release Team,
+the distribution is released.
+Releasing means
+that <em>testing</em> is renamed to <em>stable</em>,
+and a new copy is created for the new <em>testing</em>,
+and the previous <em>stable</em> is renamed to <em>oldstable</em>
+and stays there until it is finally archived.
+On archiving, the contents are moved to <tt>&archive-host;</tt>).
<p>
This development cycle is based on the assumption that the
<em>unstable</em> distribution becomes <em>stable</em> after passing a
stable distribution is incremented (e.g., ‘3.0’ becomes
‘3.0r1’, ‘2.2r4’ becomes ‘2.2r5’, and
so forth).
+Please refer to
+<qref id="upload-stable">uploads to the <em>stable</em> distribution</qref>
+for details.
<p>
Note that development under <em>unstable</em> continues during the
freeze period, since the <em>unstable</em> distribution remains in
<p>
The Incoming system is responsible for collecting updated packages and
installing them in the Debian archive. It consists of a set of
-directories and scripts that are installed both on <tt>&ftp-master-host;</tt>
-and <tt>&non-us-host;</tt>.
+directories and scripts that are installed on <tt>&ftp-master-host;</tt>.
<p>
Packages are uploaded by all the maintainers into a directory called
-<file>unchecked</file>. This directory is scanned every 15 minutes by
+<file>UploadQueue</file>.
+This directory is scanned every few minutes by a daemon called
+<prgn>queued</prgn>, <file>*.command</file>-files are executed, and
+remaining and correctly signed <file>*.changes</file>-files are moved
+together with their corresponding files to the <file>unchecked</file>
+directory.
+This directory is not visible for most Developers, as ftp-master is restricted;
+it is scanned every 15 minutes by
the <prgn>katie</prgn> script, which verifies the integrity of the uploaded
packages and their cryptographic signatures.
If the package is considered ready to be installed, it
is moved into the <file>accepted</file> directory. If this is the first upload of
-the package, it is moved to the <file>new</file> directory, where it waits
+the package (or it has new binary packages),
+it is moved to the <file>new</file> directory, where it waits
for approval by the ftpmasters. If the package contains files to be installed
"by hand" it is moved to the <file>byhand</file> directory, where it waits
for manual installation by the ftpmasters. Otherwise, if any error has been detected,
Once the package is accepted, the system sends a confirmation
mail to the maintainer and closes all the bugs marked as fixed by the upload,
and the auto-builders may start recompiling it. The package is now publicly
-accessible at <url id="&url-incoming;"> (there is no
-such URL for packages in the non-US archive) until it is really installed
-in the Debian archive. This happens only once a day, the package
+accessible at <url id="&url-incoming;">
+until it is really installed
+in the Debian archive.
+This happens only once a day
+(and is also called `dinstall run' for historical reasons);
+the package
is then removed from incoming and installed in the pool along with all
the other packages. Once all the other updates (generating new
<file>Packages</file> and <file>Sources</file> index files for example) have been
or `experimental', the announcement will be posted to
&email-debian-devel-changes; instead.
<p>
+Though ftp-master is restricted, a copy of the installation is available
+to all developers on <tt>&ftp-master-mirror;</tt>.
+<!-- FIXME: delete it or keep it for historical purposes?
+ <p>
All Debian developers have write access to the <file>unchecked</file>
directory in order to upload their packages; they also have that access
to the <file>reject</file> directory in order to remove their bad uploads
</example>
Once you've made that change, <prgn>dupload</prgn> can be used to
easily upload a package in one of the delayed directories:
-<example>DELAY=5 dupload --to delayed <changes-file></example>
-
+<example>DELAY=5 dupload -X-to delayed <changes-file></example>
+-->
<sect id="pkg-info">Package information
<sect1 id="madison">The <prgn>madison</prgn> utility
<p>
<prgn>madison</prgn> is a command-line utility that is available
-on both <tt>&ftp-master-host;</tt> and <tt>&non-us-host;</tt>. It
+on <tt>&ftp-master-host;</tt>, and on
+the mirror on <tt>&ftp-master-mirror;</tt>. It
uses a single argument corresponding to a package name. In result
it displays which version of the package is available for each
architecture and distribution combination. An example will explain
</example>
<p>
Think twice before adding a news item to the PTS because you won't be able
-to remove it later and you wan't be able to edit it either. The only thing
+to remove it later and you won't be able to edit it either. The only thing
that you can do is send a second news item that will deprecate the
information contained in the previous one.
started by Debian, and help projects whose goals are the promotion of Debian
or its derivatives.
<p>
+All Debian developers automatically have an account on Alioth.
+They can activate it by using the recover password facility.
+External developers can request guest accounts on Alioth.
+ <p>
For more information please visit <url id="&url-alioth;">.
+ <sect id="developer-misc">Goodies for Developers
+ <p>
+ <sect1 id="lwn">LWN Subscriptions
+ <p>
+Since October of 2002, HP has sponsored a subscription to LWN for all
+interested Debian developers.
+
+Details on how to get access to this benefit are in
+<url id="http://lists.debian.org/debian-devel-announce/2002/10/msg00018.html">.
+
+
<chapt id="pkgs">Managing Packages
<p>
archive maintenance software will parse the changes file and see that not
all files have been uploaded.
<p>
-<!-- FIXME: is this still topical? Explain the rationale? -->
-<em>Note:</em> Do not upload to <tt>ftp-master</tt> cryptographic
-packages which belong to <em>contrib</em> or <em>non-free</em>. Uploads of
-such software should go to <tt>non-us</tt> (see <ref
-id="upload-non-us">). Furthermore packages containing code that is
-patent-restricted by the United States government cannot be uploaded to
-<tt>ftp-master</tt>; depending on the case they may still be uploaded to
-<file>non-US/non-free</file> (it's in non-free because of distribution issues
-and not because of the license of the software). If you can't upload it to
-<tt>ftp-master</tt>, then neither can you upload it to backup
-queues that finally also end up on <tt>ftp-master</tt>. If you are not sure
-whether U.S. patent controls or cryptographic controls apply to your
-package, post a message to &email-debian-devel; and ask.
- <p>
You may also find the Debian packages <ref id="dupload"> or
<ref id="dput"> useful
when uploading packages. These handy programs help automate the
<sect1 id="upload-non-us">Uploading to <tt>non-US</tt>
<p>
-<em>Note:</em> non-us is currently not processed any more.
- <p>
-As discussed above, export controlled software should not be uploaded
-to <tt>ftp-master</tt>. Instead, upload the package with anonymous FTP
-to <ftpsite>non-us.debian.org</ftpsite>, placing the files in
-&upload-queue; (again, both <ref id="dupload"> and <ref
-id="dput"> can do this for you if invoked properly).
- <p>
-Note that U.S. residents or citizens are subject to restrictions on
-export of cryptographic software. As of this writing, U.S. citizens
-are allowed to export some cryptographic software, subject to
-notification rules by the U.S. Department of Commerce. However, this
-restriction has been waived for software which is already available
-outside the U.S. Therefore, any cryptographic software which belongs
-in the <em>main</em> section of the Debian archive and does not depend
-on any package outside of <em>main</em> (e.g., does not depend on
-anything in <em>non-US/main</em>) can be uploaded to <tt>ftp-master</tt>
-or its queues, described above.
- <p>
-Debian policy does not prevent upload to non-US by U.S. residents or
-citizens, but care should be taken in doing so. It is recommended that
-developers take all necessary steps to ensure that they are not
-breaking current US law by doing an upload to non-US, <em>including
-consulting a lawyer</em>.
- <p>
-For packages in <em>non-US/main</em>, <em>non-US/contrib</em>,
-developers should at least follow the <url id="&url-u.s.-export;"
-name="procedure outlined by the US Government">. Maintainers of
-<em>non-US/non-free</em> packages should further consult the <url
-id="&url-notification-of-export;" name="rules on notification of
-export"> of non-free software.
- <p>
-This section is for information only and does not constitute legal
-advice. Again, it is strongly recommended that U.S. citizens and
-residents consult a lawyer before doing uploads to non-US.
+<em>Note:</em> non-us was discontinued with release of sarge.
<sect1 id="delayed-incoming">Delayed uploads
<sect1>Other upload queues
<p>
-The scp queues on ftp-master, non-us, and security are mostly unusable
+The scp queues on ftp-master, and security are mostly unusable
due to the login restrictions on those hosts.
<p>
The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are
priority to the new one. Be sure to explain your reasoning.
<p>
For more information about <em>override files</em>, see <manref
-name="dpkg-scanpackages" section="8"> and
+name="dpkg-scanpackages" section="1"> and
<url id="&url-bts-devel;#maintincorrect">.
<p>
Note that the <tt>Section</tt> field describes both the section as
the bug to the right package. If you don't know which package it should
be reassigned to, you should ask for help on
<qref id="irc-channels">IRC</qref> or on &email-debian-devel;.
+Please make sure that the maintainer(s) of the package
+the bug is reassigned to
+know why you reassigned it.
<p>
Sometimes you also have to adjust the severity of the bug so that it
matches our definition of the severity. That's because people tend to
Some bugs may even be dropped to wishlist severity when the requested
change is just cosmetic.
<item>
+If the bug is real but the same problem has already been reported by
+someone else, then the two relevant bug reports should be merged
+into one using the merge command of the BTS.
+In this way, when the
+bug is fixed, all of the submitters will be informed of this.
+(Note, however, that emails sent to one bug report's submitter won't
+automatically be sent to the other report's submitter.)
+For more
+details on the technicalities of the merge command and its relative,
+the unmerge command, see the BTS control server documentation.
+ <item>
The bug submitter may have forgotten to provide some information, in which
case you have to ask them the required information. You may use the
<tt>moreinfo</tt> tag to mark the bug as such. Moreover if you can't
most concise entry and the easiest to integrate with the text of the
<file>changelog</file>.
<p>
+If an upload is identified as <qref id="nmu">Non-maintainer upload (NMU)</qref>
+(and that is the case if the name of the person who commits this change
+is not exactly the same as any one of Maintainer or Uploader,
+except if the maintainer is the qa group),
+than the bug is only tagged <tt>fixed</tt> instead of being closed.
+If a maintainer upload is targetted to experimental,
+than the tag <tt>fixed-in-experimental</tt> is added to the bug;
+for NMUs, the tag <tt>fixed</tt> is used.
+(The special rule for experimental is expected to change
+as soon as version-tracking is added to the bug tracking system.)
+ <p>
If you happen to mistype a bug number or forget a bug in the changelog
entries, don't hesitate to undo any damage the error caused. To reopen
wrongly closed bugs, send an <tt>reopen <var>XXX</var></tt> command to
whether it is already a matter of public knowledge.
<p>
-There are a few ways a developer can learn of a security problem:
+There are a few ways developers can learn of a security problem:
<list compact>
- <item>he notices it on a public forum (mailing list, web site, etc.)
+ <item>they notice it on a public forum (mailing list, web site, etc.)
<item>someone files a bug report
<item>someone informs them via private email
</list>
general interest (for instance, a flavor of Debian built with <prgn>gcc</prgn>
bounds checking). It will also enable Debian to recompile entire
distributions quickly.
- </sect2>
+ <p>
+The buildds admins of each arch can be contacted by the mail address
+$arch@buildd.debian.org.
+
+ <sect1 id="packages-arch-specific">When your package is <em>not</em> portable
+ <p>
+Some packages still have issues with building and/or working on some
+of the architectures supported by Debian, and cannot be ported at all,
+or not with a reasonable amount of time. An example is a package that
+is SVGA-specific (only i386), or uses other hardware-specific features
+not supported on all architectures.
+ <p>
+In order to prevent broken packages from being uploaded to the archive, and
+wasting buildd time, you need to do a few things:
+ <p>
+ <list>
+ <item>
+ <p>
+First, make sure your package <em>does</em> fail to build on
+architectures that it cannot support.
+There are a few ways to achieve this.
+The preferred way is to have a small testsuite during build time
+that will test the functionality, and fail if it doesn't work.
+This is a good idea anyway,
+as this will prevent (some) broken uploads on all architectures,
+and also will allow the package to build
+as soon as the required functionality is available.
+ <p>
+Additionally, if you believe the list of supported architectures is
+pretty constant, you should change 'any' to a list of supported
+architectures in debian/control. This way, the build will fail also,
+and indicate this to a human reader without actually trying.
+ <item>
+ <p>
+In order to prevent autobuilders from needlessly trying to build your
+package, it must be included in <file>packages-arch-specific</file>, a
+list used by the <prgn>wanna-build</prgn> script.
+The current version is available as
+<url id="http://cvs.debian.org/srcdep/Packages-arch-specific?rev=HEAD&cvsroot=dak&content-type=text/vnd.viewcvs-markup">;
+please see the top of the file for whom to contact for changes.
+ </list>
+ <p>
+Please note that it is insufficient to only add your package to
+Packages-arch-specific
+without making it fail to build on unsupported architectures:
+A porter or any other person trying to build your package might
+accidently upload it without noticing it doesn't work.
+If in the past some binary packages were uploaded on unsupported architectures,
+request there removal by filing a bug against
+<package>ftp.debian.org</package>
<sect id="nmu">Non-Maintainer Uploads (NMUs)
This section handles only source NMUs, i.e. NMUs which upload a new
version of the package. For binary-only NMUs by porters or QA members,
please see <ref id="binary-only-nmu">.
-For buildd uploads (which are strictly speaking also NMUs), please see <ref
-id="buildd">.
+If a buildd builds and uploads a package,
+that too is strictly speaking a binary NMU.
+See <ref id="buildd"> for some more information.
<p>
The main reason why NMUs are done is when a
developer needs to fix another developer's packages in order to
have to close the bugs that have been tagged fixed by the NMU. The easiest
way is to use the <tt>-v</tt> option of <prgn>dpkg-buildpackage</prgn>,
as this allows you to include just all changes since your last maintainer
-upload. Alternativly, you
+upload. Alternatively, you
can close them manually by sending the required mails to the
BTS or by adding the required <tt>closes: #nnnn</tt> in the changelog
entry of your next upload.
to the Bug Tracking System. Maintainers almost always appreciate
quality patches and bug reports.
+ <sect1 id="nmu-katie">How dak detects NMUs
+ <p>
+Whether an upload is treated as an NMU or as a maintainer upload by
+the archive scripts and the bugtracking system (see <ref
+id="nmu-patch">) is <em>not</em> decided by looking at the version
+number (see <ref id="nmu-version">). Instead, an upload is handled as
+an NMU if the maintainer address in the <tt>.changes</tt> file is not
+binary the same as the address in the <tt>Maintainer</tt> field, or
+any of the addresses the <tt>Uploaders</tt> field, of the <tt>dsc</tt>
+file, and also if the maintainer address is not special (i.e. it is
+not set to the QA Group address).
+
<sect1 id="nmu-terms">Terminology
<p>
There are two new terms used throughout this section: ``binary-only NMU''
<heading>Updates from unstable</heading>
<p>
The scripts that update the <em>testing</em> distribution are run each
-day after the installation of the updated packages. They generate the
+day after the installation of the updated packages;
+these scripts are called <em>britney</em>.
+They generate the
<file>Packages</file> files for the <em>testing</em> distribution, but
they do so in an intelligent manner; they try to avoid any inconsistency
and to use only non-buggy packages.
Keep in mind that packages uploaded there are not automatically processed, they
have to go through the hands of the release manager. So you'd better have a good
reason to upload there. In order to know what a good reason is in the
-release manager's eyes, you should read the instructions that he regularly
-gives on &email-debian-devel-announce;.
-<!-- FIXME: gender-specific; fix when RM is female at the very latest -->
+release managers' eyes, you should read the instructions that they regularly
+give on &email-debian-devel-announce;.
<p>
You should not upload to <em>testing-proposed-updates</em> when you can update your
packages through <em>unstable</em>. If you can't (for example because you have a
<p>
Such bugs are presumed to have an impact on the chances that the package will be released with the stable release of Debian: in general, if a package has open release-critical bugs filed on it, it won't get into "testing", and consequently won't be released in "stable".
<p>
-The "testing" bug count for a package is considered to be roughly the bug count at the last point when the "testing" version equalled the "unstable" version. The bugs tagged woody or sarge will not be counted. Bugs with the sid tag will be counted, though.
+The unstable bug count are all release-critical bugs
+without either any release-tag (such as potato, woody) or with release-tag sid;
+also, only if they are neither fixed nor set to sarge-ignore.
+The "testing" bug count for a package is considered to be roughly
+the bug count of unstable count at the last point
+when the "testing" version equalled the "unstable" version.
+ <p>
+This will change post-sarge, as soon as we have versions in the bug tracking system.
<sect2>
either to provide several flavors of the same software (e.g.,
the <package>vim</package> source package) or to make several small
packages instead of a big one (e.g., if the user can install only the
-subset she needs, and thus save some disk space).
+subset needed, and thus save some disk space).
<p>
The second case can be easily managed in <file>debian/rules</file>.
You just need to move the appropriate files from the build directory
<item>
How is this package different from the competition? Is it a better
implementation? more features? different features? Why should I
-choose this package (the second questions is about the class of packages, and
+choose this package.
+<!-- FIXME: what's this?
+(the second questions is about the class of packages, and
this about this particular package, if you have information related to both).
+-->
</list>
</sect1>
Debconf is a great tool but it is often poorly used. Many common mistakes
are listed in the <manref name="debconf-devel" section="7"> man page.
It is something that you must read if you decide to use debconf.
+Also, we document some best practices here.
+ <p>
+These guidelines include some writing style and typography
+recommendations, general considerations about debconf usage as well as
+more specific recommendations for some parts of the distribution (for
+instance, the installation system).
+
+ <sect1>Do not abuse debconf
+ <p>
+Since debconf appeared in Debian, it has been widely abused and
+several criticisms received by the Debian distribution come from
+debconf abuse with the need of answering a wide bunch of questions
+before getting any little thing installed.
+ <p>
+Keep usage notes to what they belong: the NEWS.Debian, or
+README.Debian file. Only use notes for important notes which may
+directly affect the package usability. Remember that notes will always
+block the install until confirmed or bother the user by email.
+ <p>
+Carefully choose the questions priorities in maintainer scripts. See
+<manref name="debconf-devel" section="7"> for details about priorities.
+Most questions should use medium and low priorities.
+
+ <sect1>General recommendations for authors and translators
+ <p>
+ <sect2>Write correct English
+ <p>
+Most Debian package maintainers are not native English speakers. So,
+writing properly phrased templates may not be easy for them.
+ <p>
+Please use (and abuse) &email-debian-l10n-english; mailing
+list. Have your templates proofread.
+ <p>
+Badly written templates give a poor image of your package, of your
+work...or even of Debian itself.
+ <p>
+Avoid technical jargon as much as possible. If some terms sound common
+to you, they may be impossible to understand for others. If you cannot
+avoid them, try to explain them (use the extended description). When
+doing so, try to balance between verbosity and simplicity.
+
+ <sect2>Be kind to translators
+ <p>
+Debconf templates may be translated. Debconf, along with its sister
+package <prgn>po-debconf</prgn> offers a simple framework for getting
+templates translated by translation teams or even individuals.
+ <p>
+Please use gettext-based templates. Install <package>po-debconf</package> on your
+development system and read its documentation ("man po-debconf" is a
+good start).
+ <p>
+Avoid changing templates too often. Changing templates text induces
+more work to translators which will get their translation "fuzzied". If
+you plan changes to your original templates, please contact
+translators. Most active translators are very reactive and getting
+their work included along with your modified templates will save you
+additional uploads. If you use gettext-based templates, the
+translator's name and e-mail addresses are mentioned in the po files
+headers.
+ <p>
+The use of the <prgn>podebconf-report-po</prgn> from the
+po-debconf package is highly recommended to warn translators which
+have incomplete translations and request them for updates.
+ <p>
+If in doubt, you may also contact the translation team for a given
+language (debian-l10n-xxxxx@lists.debian.org), or the
+&email-debian-i18n; mailing list.
+ <p>
+Calls for translations posted to
+&email-debian-i18n; with the <file>debian/po/templates.pot</file> file
+attached or referenced in a URL are encouraged. Be sure to mentions in
+these calls for new translations which languages you have existing
+translations for, in order to avoid duplicate work.
+ <sect2>Unfuzzy complete translations when correcting typos and spelling
+ <p>
+
+When the text of a debconf template is corrected and you are
+<strong>sure</strong> that the change does <strong>not</strong> affect
+translations, please be kind to translators and unfuzzy their
+translations.
+ <p>
+If you don't do so, the whole template will not be translated as long
+as a translator will send you an update.
+ <p>
+To <strong>unfuzzy</strong> translations, you can proceed the following way:
+ <enumlist>
+ <item>
+Put all incomplete PO files out of the way. You can check the
+completeness by using (needs the <package>gettext</package> package installed):
+<example>for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null
+--statistics $i; done</example>
+ <item>
+move all files which report either fuzzy strings to a temporary
+place. Files which report no fuzzy strings (only translated and
+untranslated) will be kept in place.
+ <item>
+now <strong>and now only</strong>, modify the template for the typos
+and check again that translation are not impacted (typos, spelling
+errors, sometimes typographical corrections are usually OK)
+ <item>
+run <prgn>debconf-updatepo</prgn>. This will fuzzy all strings
+you modified in translations. You can see this by running the above
+again
+ <item>
+use the following command:
+<example>for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done</example>
+ <item>
+move back to debian/po the files which showed fuzzy strings in the first step
+ <item>
+run <prgn>debconf-updatepo</prgn> again
+ </enumlist>
+ <sect2>Do not make assumptions about interfaces
+ <p>
+Templates text should not make reference to widgets belonging to some
+debconf interfaces. Sentences like "If you answer Yes..." have no
+meaning for users of graphical interfaces which use checkboxes for
+boolean questions.
+ <p>
+String templates should also avoid mentioning the default values in
+their description. First, because this is redundant with the values
+seen by the users. Also, because these default values may be different
+from the maintainer choices (for instance, when the debconf database
+was preseeded).
+ <p>
+More generally speaking, try to avoid referring to user actions.
+Just give facts.
+
+ <sect2>Do not use first person
+ <p>
+You should avoid the use of first person ("I will do this..." or "We
+recommend..."). The computer is not a person and the Debconf templates
+do not speak for the Debian developers. You should use neutral
+construction and often the passive form. Those of you who already
+wrote scientific publications, just write your templates like you
+would write a scientific paper.
+
+ <sect2>Be gender neutral
+ <p>
+The world is made of men and women. Please use gender-neutral
+constructions in your writing. This is not Political Correctness, this
+is showing respect to all humanity.
+
+
+ <sect1>Templates fields definition
+ <p>
+This part gives some information which is mostly taken from the
+<manref name="debconf-devel" section="7"> manual page.
+
+ <sect2>Type
+ <p>
+
+ <sect3>string:
+ <p>
+Results in a free-form input field that the user can type any string into.
+
+ <sect3>password:
+ <p>
+Prompts the user for a password. Use this with caution; be aware that
+the password the user enters will be written to debconf's
+database. You should probably clean that value out of the database as
+soon as is possible.
+
+ <sect3>boolean:
+ <p>
+A true/false choice. Remember: true/false, NOT YES/NO...
+
+ <sect3>select:
+ <p>
+A choice between one of a number of values. The choices must be
+specified in a field named 'Choices'. Separate the possible values
+with commas and spaces, like this: Choices: yes, no, maybe
+
+ <sect3>multiselect:
+ <p>
+Like the select data type, except the user can choose any number of
+
+ items from the choices list (or chose none of them).
+
+ <sect3>note:
+ <p>
+Rather than being a question per se, this datatype indicates a note
+that can be displayed to the user. It should be used only for
+important notes that the user really should see, since debconf will go
+to great pains to make sure the user sees it; halting the install for
+them to press a key, and even mailing the note to them in some
+cases.
+
+ <sect3>text:
+ <p>
+This type is now considered obsolete: don't use it.
+
+ <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
+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).
+
+
+ <sect2>Description: short and extended description
+ <p>
+Templates descriptions have two parts: short and extended. The short
+description is in the "Description:" line of the template.
+ <p>
+The short description should be kept short (50 characters or so) so
+that it may be accomodated by most debconf interfaces. Keeping it
+short also helps translators, as usually translations tend to end up
+being longer than the original.
+ <p>
+The short description should be able to stand on its own. Some
+interfaces do not show the long description by default, or only if the
+user explicitely asks for it or even do not show it at all. Avoid
+things like "What do you want to do?"
+ <p>
+The short description does not necessarily have to be a full
+sentence. This is part of the "keep it short and efficient"
+recommendation.
+ <p>
+The extended description should not repeat the short description word
+for word. If you can't think up a long description, then first, think
+some more. Post to debian-devel. Ask for help. Take a writing class!
+That extended description is important. If after all that you still
+can't come up with anything, leave it blank.
+ <p>
+The extended description should use complete sentences. Paragraphs
+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.
+ <p>
+For specific rules depending on templates type (string, boolean,
+etc.), please read below.
+
+ <sect2>Choices
+ <p>
+This field should be used for Select and Multiselect types. It
+contains the possible choices which will be presented to users. These
+choices should be separated by commas.
+
+
+ <sect2>Default
+ <p>
+This field is optional. It contains the default answer for string,
+select and multiselect templates. For multiselect templates, it may
+contain a comma-separated list of choices.
+
+ <sect1>Templates fields specific style guide
+ <p>
+
+ <sect2>Type field
+ <p>
+No specific indication except: use the appropriate type by referring
+to the previous section.
+
+ <sect2>Description field
+ <p>
+Below are specific instructions for properly writing the Description
+(short and extended) depending on the template type.
+
+ <sect3>String/password templates
+ <p>
+<list>
+<item> The short description is a prompt and NOT a title. Avoid
+ question style prompts ("IP Address?") in favour of
+ "opened" prompts ("IP address:").
+ The use of colons is recommended.
+
+<item> The extended description is a complement to the short description.
+ In the extended part, explain what is being asked, rather than ask
+ the same question again using longer words. Use complete sentences.
+ Terse writing style is strongly discouraged.
+</list>
+
+ <sect3>Boolean templates
+ <p>
+<list>
+<item> The short description should be phrased in the form of a question
+ which should be kept short and should generally end with a question
+ mark. Terse writing style is permitted and even encouraged if the
+ question is rather long (remember that translations are often longer
+ than original versions)
+
+<item> The extended description should NOT include a question.
+
+<item> Again, please avoid referring to specific interface widgets. A common
+ mistake for such templates is "if you answer Yes"-type
+ constructions.
+</list>
+
+ <sect3>Select/Multiselect
+ <p>
+<list>
+<item> The short description is a prompt and NOT a title. Do NOT use useless
+ "Please choose..." constructions. Users are clever enough to figure
+ out they have to choose something...:)
+
+<item> The extended description will complete the short description. It may
+ refer to the available choices. It may also mention that the user
+ may choose more than one of the available choices, if the template
+ is a multiselect one (although the interface often makes this
+ clear).
+</list>
+
+ <sect3>Notes
+ <p>
+<list>
+<item> The short description should be considered to be a *title*.
+
+<item> The extended description is what will be displayed as a more detailed
+ explanation of the note. Phrases, no terse writing style.
+
+<item> DO NOT ABUSE DEBCONF. Notes are the most common way to abuse
+ debconf. As written in debconf-devel manual page: it's best to use them
+ only for warning about very serious problems. The NEWS.Debian or
+ README.Debian files are the appropriate location for a lot of notes.
+ If, by reading this, you consider converting your Note type templates
+ to entries in NEWS/Debian or README.Debian, plus consider keeping existing
+ translations for the future.
+</list>
+
+
+ <sect2>Choices field
+ <p>
+If the Choices are likely to change often, please consider using the
+"__Choices" trick. This will split each individual choice into a
+single string, which will considerably help translators for doing
+their work.
+
+ <sect2>Default field
+ <p>
+If the default value, for a "select" template, is likely to vary
+depending on the user language (for instance, if the choice is a
+language choice), please use the "_DefaultChoice" trick.
+ <p>
+This special field allow translators to put the most appropriate
+choice according to their own language. It will become the default
+choice when their language is used while your own mentioned Default
+Choice will be used chan using English.
+ <p>
+Example, taken from the geneweb package templates:
+<example>
+Template: geneweb/lang
+Type: select
+__Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv)
+# This is the default choice. Translators may put their own language here
+# instead of the default.
+# WARNING : you MUST use the ENGLISH FORM of your language
+# For instance, the french translator will need to put "French (fr)" here.
+_DefaultChoice: English (en)[ translators, please see comment in PO files]
+_Description: Geneweb default language:
+</example>
+ <p>
+Note the use of brackets which allow internal comments in debconf
+fields. Also note the use of comments which will show up in files the
+translators will work with.
+ <p>
+The comments are needed as the DefaultChoice trick is a bit
+confusing: the translators may put their own choice
+
+ <sect2>Default field
+ <p>
+Do NOT use empty default field. If you don't want to use default
+values, do not use Default at all.
+ <p>
+If you use po-debconf (and you SHOULD, see 2.2), consider making this
+field translatable, if you think it may be translated.
+ <p>
+If the default value may vary depending on language/country (for
+instance the default value for a language choice), consider using the
+special "_DefaultChoice" type documented in <manref name="po-debconf" section="7">).
</sect>
<example>apt-cache search .|grep transitional</example>.
</sect1>
+
+ <sect1 id="bpp-origtargz">
+ <heading>Best practices for <file>orig.tar.gz</file> files</heading>
+ <p>
+ There are two kinds of original source tarballs: Pristine source
+ and repackaged upstream source.
+ </p>
+ <sect2 id="pristine source">
+ <heading>Pristine source</heading>
+ <p>
+The defining characteristic of a pristine source tarball is that the
+.orig.tar.gz file is byte-for-byte identical to a tarball officially
+distributed by the upstream author.
+<footnote>
+We cannot prevent upstream authors from changing the tarball
+they distribute without also upping the version number, so
+there can be no guarantee that a pristine tarball is identical
+to what upstream <em>currently</em> distributing at any point in
+time. All that can be expected is that it is identical to
+something that upstream once <em>did</em> distribute.
+
+If a difference arises later (say, if upstream notices that he wasn't
+using maximal comression in his original distribution and then
+re-<tt>gzip</tt>s it), that's just too bad. Since there is no good way
+to upload a new .orig.tar.gz for the same version, there is not even
+any point in treating this situation as a bug.
+</footnote>
+This makes it possible to use checksums to easily verify that all
+changes between Debian's version and upstream's are contained in the
+Debian diff. Also, if the original source is huge, upstream authors
+and others who already have the upstream tarball can save download
+time if they want to inspect your packaging in detail.
+ </p>
+ <p>
+There is no universally accepted guidelines that upstream authors
+follow regarding to the directory structure inside their tarball, but
+<prgn>dpkg-source</prgn> is nevertheless able to deal with most
+upstream tarballs as pristine source. Its strategy is equivalent to
+the following:
+ </p>
+ <p>
+ <enumlist>
+ <item>
+It unpacks the tarball in an empty temporary directory by doing
+
+<example>
+zcat path/to/<packagename>_<upstream-version>.orig.tar.gz | tar xf - +</example>
+ </item>
+ <item>
+If, after this, the temporary directory contains nothing but one
+directory and no other files, <prgn>dpkg-source</prgn> renames that
+directory to
+<tt><packagename>-<upstream-version>(.orig)</tt>. The name
+of the top-level directory in the tarball does not matter, and is
+forgotten.
+ </item>
+ <item>
+Otherwise, the upstream tarball must have been packaged without a
+common top-level directory (shame on the upstream author!). In this
+case, <prgn>dpkg-source</prgn> renames the temporary directory
+<em>itself</em> to
+<tt><packagename>-<upstream-version>(.orig)</tt>.
+ </item>
+ </enumlist>
+ </p>
+ </sect2>
+ <sect2 id="repackaged origtargz">
+ <heading>Repackaged upstream source</heading>
+ <p>
+You <strong>should</strong> upload packages with a pristine source
+tarball if possible, but there are various reasons why it might not be
+possible. This is the case if upstream does not distribute the source
+as gzipped tar at all, or if upstream's tarball contains non-DFSG-free
+material that you must remove before uploading.
+ </p>
+ <p>
+In these cases the developer must construct a suitable .orig.tar.gz
+file himself. We refer to such a tarball as a "repackaged upstream
+source". Note that a "repackaged upstream source" is different from a
+Debian-native package. A repackaged source still comes with
+Debian-specific changes in a separate <tt>.diff.gz</tt> and still has
+a version number composed of <tt><upstream-version></tt> and
+<tt><debian-revision></tt>.
+ </p>
+ <p>
+There may be cases where it is desirable to repackage the source even
+though upstream distributes a <tt>.tar.gz</tt> that could in principle
+be used in its pristine form. The most obvious is if
+<em>significant</em> space savings can be achieved by recompressing
+the tar archive or by removing genuinely useless cruft from the
+upstream archive. Use your own discretion here, but be prepared to
+defend your decision if you repackage source that could have been
+pristine.
+ </p>
+ <p>
+A repackaged .orig.tar.gz
+ </p>
+ <p>
+ <enumlist>
+ <item>
+<p>
+<strong>must</strong> contain detailed information how
+the repackaged source was obtained, and how this can be reproduced, in
+<file>README.Debian-source</file> or a similar file. This file should
+be in the <file>diff.gz</file> part of the Debian source package,
+usually in the <file>debian</file> directory, <em>not</em> in the
+repackaged <file>orig.tar.gz</file>. It is also a good idea to provide a
+<tt>get-orig-source</tt> target in your <file>debian/rules</file> file
+that repeats the process, as described in the Policy Manual, <url
+id="&url-debian-policy;ch-source.html#s-debianrules" name="Main
+building script: debian/rules">.
+</p>
+ </item>
+ <item>
+<strong>should not</strong> contain any file that does not come from the
+upstream author(s), or whose contents has been changed by you.
+<footnote>
+As a special exception, if the omission of non-free files would lead
+to the source failing to build without assistance from the Debian
+diff, it might be appropriate to instead edit the files, omitting only
+the non-free parts of them, and/or explain the situation in a
+README.Debian-source <!-- or similarly named --> file in the root of the source
+tree. But in that case please also urge the upstream author to make
+the non-free components easier seperable from the rest of the source.
+</footnote>
+ </item>
+ <item>
+<p>
+<strong>should</strong>, except where impossible for legal reasons,
+preserve the entire building and portablility infrastructure provided
+by the upstream author. For example, it is not a sufficient reason for
+omitting a file that it is used only when building on
+MS-DOS. Similarly, a Makefile provided by upstream should not be
+omitted even if the first thing your <file>debian/rules</file> does is
+to overwrite it by running a configure script.
+</p>
+<p>
+(<em>Rationale:</em> It is common for Debian users who need to build
+software for non-Debian platforms to fetch the source from a Debian
+mirror rather than trying to locate a canonical upstream distribution
+point).
+</p> </item>
+ <item>
+<strong>should</strong> use
+<tt><packagename>-<upstream-version>.orig</tt> as the name
+of the top-level directory in its tarball. This makes it possible to
+distinguish pristine tarballs from repackaged ones. + </item>
+ <item>
+<strong>should</strong> be gzipped with maximal compression.
+ </item>
+ </enumlist>
+ </p>
+ <p>
+The canonical way to meet the latter two points is to let
+<tt>dpkg-source -b</tt> construct the repackaged tarball from an
+unpacked directory.
+ </p>
+ </sect2>
+ <sect2 id="changed-binfiles">
+ <heading>Changing binary files in <tt>diff.gz</tt></heading>
+ <p>
+Sometimes it is necessary to change binary files contained in the
+original tarball, or to add binary files that are not in it.
+If this is done by simply copying the files into the debianized source
+tree, <prgn>dpkg-source</prgn> will not be able to handle this. On the
+other hand, according to the guidelines given above, you cannot
+include such a changed binary file in a repackaged
+<file>orig.tar.gz</file>. Instead, include the file in the
+<file>debian</file> directory in <prgn>uuencode</prgn>d (or similar)
+form
+<footnote>
+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.
+</footnote>.
+The file would then be decoded and copied to its place during the
+build process. Thus the change will be visible quite easy.
+</p>
+<p>
+Some packages use <prgn>dbs</prgn> to manage patches to their upstream
+source, and always create a new <tt>orig.tar.gz</tt> file that
+contains the real <tt>orig.tar.gz</tt> in its toplevel directory. This
+is questionable with respect to the preference for pristine source. On
+the other hand, it is easy to modify or add binary files in this case:
+Just put them into the newly created <tt>orig.tar.gz</tt> file,
+besides the real one, and copy them to the right place during the
+build process.
+ </p>
+ </sect2>
+ </sect1>
+
+
</sect>
</chapt>
out all the bugs you submitted, you just have to visit
<tt>http://&bugs-host;/from:<var><your-email-addr></var></tt>.
- <sect1 id="submit-many-bugs">Reporting lots of bugs at once
+ <sect1 id="submit-many-bugs">Reporting lots of bugs at once (mass bug filing)
<p>
Reporting a great number of bugs for the same problem on a great
number of different packages — i.e., more than 10 — is a deprecated
<p>
If you report more than 10 bugs on the same topic at once, it is
recommended that you send a message to &email-debian-devel; describing
-your intention before submitting the report. This will allow other
+your intention before submitting the report, and mentioning the
+fact in the subject of your mail. This will allow other
developers to verify that the bug is a real problem. In addition, it
will help prevent a situation in which several maintainers start
filing the same bug report simultaneously.
able to do it on their own, a new maintainer applicant. Sponsoring a package
also means accepting responsibility for it.
<p>
+ <!-- FIXME: service down
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.
~ianmdlvl / developers-reference.git / blobdiff