[developers-reference.git] / resources.dbk

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
    "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
  <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
]>
<chapter id="resources">
<title>Resources for Debian Developers</title>
<para>
In this chapter you will find a very brief road map of the Debian mailing
lists, the Debian machines which may be available to you as a developer, and
all the other resources that are available to help you in your maintainer work.
</para>
<section id="mailing-lists">
<title>Mailing lists</title>
<para>
Much of the conversation between Debian developers (and users) is managed
through a wide array of mailing lists we host at <literal><ulink
url="http://&lists-host;/">&lists-host;</ulink></literal>.
To find out more on how to subscribe or unsubscribe, how to post and how not to
post, where to find old posts and how to search them, how to contact the list
maintainers and see various other information about the mailing lists, please
read <ulink url="&url-debian-lists;"></ulink>.  This section
will only cover aspects of mailing lists that are of particular interest to
developers.
</para>
<section id="mailing-lists-rules">
<title>Basic rules for use</title>
<para>
When replying to messages on the mailing list, please do not send a carbon copy
(<literal>CC</literal>) to the original poster unless they explicitly request
to be copied.  Anyone who posts to a mailing list should read it to see the
responses.
</para>
<para>
Cross-posting (sending the same message to multiple lists) is discouraged.  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.
</para>
<para>
Please read the <ulink
url="&url-debian-lists;#codeofconduct">code of conduct</ulink>
for more information. The <ulink url="&url-dcg;">Debian Community
Guidelines</ulink> are also worth reading.
</para>
</section>

<section id="core-devel-mailing-lists">
<title>Core development mailing lists</title>
<para>
The core Debian mailing lists that developers should use are:
</para>
<itemizedlist>
<listitem>
<para>
&email-debian-devel-announce;, used to announce important
things to developers.  All developers are expected to be subscribed to this
list.
</para>
</listitem>
<listitem>
<para>
&email-debian-devel;, used to discuss various development
related technical issues.
</para>
</listitem>
<listitem>
<para>
&email-debian-policy;, where the Debian Policy is discussed
and voted on.
</para>
</listitem>
<listitem>
<para>
&email-debian-project;, used to discuss various non-technical
issues related to the project.
</para>
</listitem>
</itemizedlist>
<para>
There are other mailing lists available for a variety of special topics; see
<ulink url="http://&lists-host;/"></ulink> for a list.
</para>
</section>

<section id="mailing-lists-special">
<title>Special lists</title>
<para>
&email-debian-private; is a special mailing list for private
discussions amongst Debian developers.  It is meant to be used for posts which
for whatever reason should not be published publicly.  As such, it is a low
volume list, and users are urged not to use
&email-debian-private; unless it is really necessary.
Moreover, do <emphasis>not</emphasis> forward email from that list to anyone.
Archives of this list are not available on the web for obvious reasons, but you
can see them using your shell account on <literal>&lists-host;</literal>
and looking in the <filename>&file-debian-private-archive;</filename>
directory.
</para>
<para>
&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.
</para>
</section>

<section id="mailing-lists-new">
<title>Requesting new development-related lists</title>
<para>
Before requesting a mailing list that relates to the development of a package
(or a small group of related packages), please consider if using an alias (via
a .forward-aliasname file on master.debian.org, which translates into a
reasonably nice <replaceable>you-aliasname@debian.org</replaceable> address) or
a self-managed mailing list on <link linkend="alioth">Alioth</link> is
more appropriate.
</para>
<para>
If you decide that a regular mailing list on &lists-host; is really what
you want, go ahead and fill in a request, following <ulink
url="&url-debian-lists-new;">the HOWTO</ulink>.
</para>
</section>

</section>

<section id="irc-channels">
<title>IRC channels</title>
<para>
Several IRC channels are dedicated to Debian's development.  They are mainly
hosted on the <ulink url="&url-oftc;">Open and free technology
community (OFTC)</ulink> network.  The <literal>irc.debian.org</literal> DNS
entry is an alias to <literal>irc.oftc.net</literal>.
</para>
<para>
The main channel for Debian in general is <emphasis>#debian</emphasis>.  This
is a large, general-purpose channel where users can find recent news in the
topic and served by bots.  <emphasis>#debian</emphasis> is for English
speakers; there are also <emphasis>#debian.de</emphasis>,
<emphasis>#debian-fr</emphasis>, <emphasis>#debian-br</emphasis> and other
similarly named channels for speakers of other languages.
</para>
<para>
The main channel for Debian development is <emphasis>#debian-devel</emphasis>.
It is a very active channel since usually over 150 people are always logged in.
It's a channel for people who work on Debian, it's not a support channel
(there's <emphasis>#debian</emphasis> for that).  It is however open to anyone
who wants to lurk (and learn).  Its topic is commonly full of interesting
information for developers.
</para>
<para>
Since <emphasis>#debian-devel</emphasis> is an open channel, you should not
speak there of issues that are discussed in
&email-debian-private;.  There's another channel for this
purpose, it's called <emphasis>#debian-private</emphasis> and it's protected by
a key.  This key is available in the archives of debian-private in
<filename>master.debian.org:&file-debian-private-archive;</filename>,
just <command>zgrep</command> for <emphasis>#debian-private</emphasis> in all
the files.
</para>
<para>
There are other additional channels dedicated to specific subjects.
<emphasis>#debian-bugs</emphasis> is used for coordinating bug squashing
parties.  <emphasis>#debian-boot</emphasis> is used to coordinate the work on
the debian-installer.  <emphasis>#debian-doc</emphasis> is occasionally used to
talk about documentation, like the document you are reading.  Other channels
are dedicated to an architecture or a set of packages:
<emphasis>#debian-kde</emphasis>, <emphasis>#debian-dpkg</emphasis>,
<emphasis>#debian-jr</emphasis>, <emphasis>#debian-edu</emphasis>,
<emphasis>#debian-oo</emphasis> (OpenOffice package) ...
</para>
<para>
Some non-English developers' channels exist as well, for example
<emphasis>#debian-devel-fr</emphasis> for French speaking people interested in
Debian's development.
</para>
<para>
Channels dedicated to Debian also exist on other IRC networks, notably on the
<ulink url="&url-openprojects;">freenode</ulink> IRC network,
which was pointed at by the <literal>irc.debian.org</literal> alias until 4th
June 2006.
</para>
<para>
To get a cloak on freenode, you send Jörg Jaspert &lt;joerg@debian.org&gt; a
signed mail where you tell what your nick is.  Put cloak somewhere in the
Subject: header.  The nick should be registered: <ulink
url="http://freenode.net/faq.shtml#nicksetup">Nick Setup Page</ulink>.  The
mail needs to be signed by a key in the Debian keyring.  Please see <ulink
url="http://freenode.net/faq.shtml#projectcloak">Freenodes
documentation</ulink> for more information about cloaks.
</para>
</section>

<section id="doc-rsrcs">
<title>Documentation</title>
<para>
This document contains a lot of information which is useful to Debian
developers, but it cannot contain everything.  Most of the other interesting
documents are linked from <ulink url="&url-devel-docs;">The
Developers' Corner</ulink>.  Take the time to browse all the links, you will
learn many more things.
</para>
</section>

<section id="server-machines">
<title>Debian machines</title>
<para>
Debian has several computers working as servers, most of which serve critical
functions in the Debian project.  Most of the machines are used for porting
activities, and they all have a permanent connection to the Internet.
</para>
<para>
Some of the machines are available for individual developers to use, as long as
the developers follow the rules set forth in the <ulink
url="&url-dmup;">Debian Machine Usage Policies</ulink>.
</para>
<para>
Generally speaking, you can use these machines for Debian-related purposes as
you see fit.  Please be kind to system administrators, and do not use up tons
and tons of disk space, network bandwidth, or CPU without first getting the
approval of the system administrators.  Usually these machines are run by
volunteers.
</para>
<para>
Please take care to protect your Debian passwords and SSH keys installed on
Debian machines.  Avoid login or upload methods which send passwords over the
Internet in the clear, such as telnet, FTP, POP etc.
</para>
<para>
Please do not put any material that doesn't relate to Debian on the Debian
servers, unless you have prior permission.
</para>
<para>
The current list of Debian machines is available at <ulink
url="&url-devel-machines;"></ulink>.  That web page contains
machine names, contact information, information about who can log in, SSH keys
etc.
</para>
<para>
If you have a problem with the operation of a Debian server, and you think that
the system operators need to be notified of this problem, you can check
the list of open issues in the DSA queue of our request tracker at <ulink
url="&url-rt;" /> (you can login with user "guest" and password "readonly").
To report a new problem, simply send a mail to &email-rt-dsa; and make
sure to put the string "Debian RT" somewhere in the subject.
</para>
<para>
If you have a problem with a certain service, not related to the system
administration (such as packages to be removed from the archive, suggestions
for the web site, etc.), generally you'll report a bug against a
``pseudo-package''.  See <xref linkend="submit-bug"/> for information on how to
submit bugs.
</para>
<para>
Some of the core servers are restricted, but the information from there is
mirrored to another server.
</para>
<section id="servers-bugs">
<title>The bugs server</title>
<para>
<literal>&bugs-host;</literal> is the canonical location for
the Bug Tracking System (BTS).
</para>
<para>
It is restricted; a mirror is available on <literal>merkel</literal>.
</para>
<para>
If you plan on doing some statistical analysis or processing of Debian bugs,
this would be the place to do it.  Please describe your plans on
&email-debian-devel; before implementing anything, however, to
reduce unnecessary duplication of effort or wasted processing time.
</para>
</section>

<section id="servers-ftp-master">
<title>The ftp-master server</title>
<para>
The <literal>&ftp-master-host;</literal> server holds the canonical copy of
the Debian archive.  Generally, package uploads go to this server; see
<xref linkend="upload"/>.
</para>
<para>
It is restricted; a mirror is available on <literal>merkel</literal>.
</para>
<para>
Problems with the Debian FTP archive generally need to be reported as bugs
against the <systemitem role="package">&ftp-debian-org;</systemitem>
pseudo-package or an email to &email-ftpmaster;, but also see
the procedures in <xref linkend="archive-manip"/> .
</para>
</section>

<section id="servers-www">
<title>The www-master server</title>
<para>
The main web server is <literal>www-master.debian.org</literal>.  It holds the
official web pages, the face of Debian for most newbies.
</para>
<para>
If you find a problem with the Debian web server, you should generally submit a
bug against the pseudo-package, <systemitem
role="package">www.debian.org</systemitem>.  Remember to check whether or not
someone else has already reported the problem to the <ulink
url="http://&bugs-host;/&www-debian-org;">Bug Tracking System</ulink>.
</para>
</section>

<section id="servers-people">
<title>The people web server</title>
<para>
<literal>people.debian.org</literal> is the server used for developers' own web
pages about anything related to Debian.
</para>
<para>
If you have some Debian-specific information which you want to serve on the
web, you can do this by putting material in the
<filename>public_html</filename> directory under your home directory on
<literal>people.debian.org</literal>.  This will be accessible at the URL
<literal>http://people.debian.org/~<replaceable>your-user-id</replaceable>/</literal>.
</para>
<para>
You should only use this particular location because it will be backed up,
whereas on other hosts it won't.
</para>
<para>
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.
</para>
<para>
Send mail to &email-debian-devel; if you have any questions.
</para>
</section>

<section id="servers-cvs">
<title>The CVS server</title>
<!-- TODO: document svn.debian.org, arch.debian.org also -->
<para>
Our CVS server is located on <literal>cvs.debian.org</literal>.
</para>
<para>
If you need to use a publicly accessible CVS server, for instance, to help
coordinate work on a package between many different developers, you can request
a CVS area on the server.
</para>
<para>
Generally, <literal>cvs.debian.org</literal> offers a combination of local CVS
access, anonymous client-server read-only access, and full client-server access
through <command>ssh</command>.  Also, the CVS area can be accessed read-only
via the Web at <ulink url="&url-cvsweb;"></ulink>.
</para>
<para>
To request a CVS area, send a request via email to
&email-debian-admin;.  Include the name of the requested CVS
area, the Debian account that should own the CVS root area, and why you need
it.
</para>
</section>

<section id="dchroot">
<title>chroots to different distributions</title>
<para>
On some machines, there are chroots to different distributions available.  You
can use them like this:
</para>
<screen>
vore$ dchroot unstable
Executing shell in chroot: /org/vore.debian.org/chroots/user/unstable
</screen>
<para>
In all chroots, the normal user home directories are available.  You can find
out which chroots are available via
<literal>&url-devel-machines;</literal>.
</para>
</section>

</section>

<section id="devel-db">
<title>The Developers Database</title>
<para>
The Developers Database, at <ulink
url="&url-debian-db;"></ulink>, is an LDAP directory for
managing Debian developer attributes.  You can use this resource to search the
list of Debian developers.  Part of this information is also available through
the finger service on Debian servers, try <command>finger
yourlogin@db.debian.org</command> to see what it reports.
</para>
<para>
Developers can <ulink url="&url-debian-db-login;">log into the
database</ulink> to change various information about themselves, such as:
</para>
<itemizedlist>
<listitem>
<para>
forwarding address for your debian.org email
</para>
</listitem>
<listitem>
<para>
subscription to debian-private
</para>
</listitem>
<listitem>
<para>
whether you are on vacation
</para>
</listitem>
<listitem>
<para>
personal information such as your address, country, the latitude and longitude
of the place where you live for use in <ulink
url="&url-worldmap;">the world map of Debian
developers</ulink>, phone and fax numbers, IRC nickname and web page
</para>
</listitem>
<listitem>
<para>
password and preferred shell on Debian Project machines
</para>
</listitem>
</itemizedlist>
<para>
Most of the information is not accessible to the public, naturally.  For more
information please read the online documentation that you can find at <ulink
url="&url-debian-db-doc;"></ulink>.
</para>
<para>
Developers can also submit their SSH keys to be used for authorization on the
official Debian machines, and even add new *.debian.net DNS entries.  Those
features are documented at <ulink
url="&url-debian-db-mail-gw;"></ulink>.
</para>
</section>

<section id="archive">
<title>The Debian archive</title>
<para>
The &debian-formal; distribution consists of a lot of packages
(<filename>.deb</filename>'s, currently around
&number-of-pkgs;) and a few additional files (such as
documentation and installation disk images).
</para>
<para>
Here is an example directory tree of a complete Debian archive:
</para>
&sample-dist-dirtree;
<para>
As you can see, the top-level directory contains two directories,
<filename>dists/</filename> and <filename>pool/</filename>.  The latter is a
“pool” in which the packages actually are, and which is handled by the
archive maintenance database and the accompanying programs.  The former
contains the distributions, <emphasis>stable</emphasis>,
<emphasis>testing</emphasis> and <emphasis>unstable</emphasis>.  The
<filename>Packages</filename> and <filename>Sources</filename> files in the
distribution subdirectories can reference files in the
<filename>pool/</filename> directory.  The directory tree below each of the
distributions is arranged in an identical manner.  What we describe below for
<emphasis>stable</emphasis> is equally applicable to the
<emphasis>unstable</emphasis> and <emphasis>testing</emphasis> distributions.
</para>
<para>
<filename>dists/stable</filename> contains three directories, namely
<filename>main</filename>, <filename>contrib</filename>, and
<filename>non-free</filename>.
</para>
<para>
In each of the areas, there is a directory for the source packages
(<filename>source</filename>) and a directory for each supported architecture
(<filename>binary-i386</filename>, <filename>binary-m68k</filename>, etc.).
</para>
<para>
The <filename>main</filename> area contains additional directories which hold
the disk images and some essential pieces of documentation required for
installing the Debian distribution on a specific architecture
(<filename>disks-i386</filename>, <filename>disks-m68k</filename>, etc.).
</para>
<section id="archive-sections">
<title>Sections</title>
<para>
The <emphasis>main</emphasis> section of the Debian archive is what makes up
the <emphasis role="strong">official &debian-formal; distribution</emphasis>.
The <emphasis>main</emphasis> section is official because it fully complies
with all our guidelines.  The other two sections do not, to different degrees;
as such, they are <emphasis role="strong">not</emphasis> officially part of
&debian-formal;.
</para>
<para>
Every package in the main section must fully comply with the <ulink
url="&url-dfsg;">Debian Free Software
Guidelines</ulink> (DFSG) and with all other policy requirements as described
in the <ulink url="&url-debian-policy;">Debian Policy
Manual</ulink>.  The DFSG is our definition of “free software.” Check out
the Debian Policy Manual for details.
</para>
<para>
Packages in the <emphasis>contrib</emphasis> section have to comply with the
DFSG, but may fail other requirements.  For instance, they may depend on
non-free packages.
</para>
<para>
Packages which do not conform to the DFSG are placed in the
<emphasis>non-free</emphasis> section.  These packages are not considered as
part of the Debian distribution, though we support their use, and we provide
infrastructure (such as our bug-tracking system and mailing lists) for non-free
software packages.
</para>
<para>
The <ulink url="&url-debian-policy;">Debian Policy
Manual</ulink> contains a more exact definition of the three sections.  The
above discussion is just an introduction.
</para>
<para>
The separation of the three sections at the top-level of the archive is
important for all people who want to distribute Debian, either via FTP servers
on the Internet or on CD-ROMs: by distributing only the
<emphasis>main</emphasis> and <emphasis>contrib</emphasis> sections, one can
avoid any legal risks.  Some packages in the <emphasis>non-free</emphasis>
section do not allow commercial distribution, for example.
</para>
<para>
On the other hand, a CD-ROM vendor could easily check the individual package
licenses of the packages in <emphasis>non-free</emphasis> and include as 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.)
</para>
<para>
Note that the term section is also used to refer to categories which simplify
the organization and browsing of available packages, e.g.
<emphasis>admin</emphasis>, <emphasis>net</emphasis>,
<emphasis>utils</emphasis> etc.  Once upon a time, these sections (subsections,
rather) existed in the form of subdirectories within the Debian archive.
Nowadays, these exist only in the Section header fields of packages.
</para>
</section>

<section id="s4.6.2">
<title>Architectures</title>
<para>
In the first days, the Linux kernel was only available for Intel i386 (or
greater) platforms, and so was Debian.  But as Linux became more and more
popular, the kernel was ported to other architectures, too.
</para>
<para>
The Linux 2.0 kernel supports Intel x86, DEC Alpha, SPARC, Motorola 680x0 (like
Atari, Amiga and Macintoshes), MIPS, and PowerPC.  The Linux 2.2 kernel
supports even more architectures, including ARM and UltraSPARC.  Since Linux
supports these platforms, Debian decided that it should, too.  Therefore,
Debian has ports underway; in fact, we also have ports underway to non-Linux
kernels.  Aside from <emphasis>i386</emphasis> (our name for Intel x86), there
is <emphasis>m68k</emphasis>, <emphasis>alpha</emphasis>,
<emphasis>powerpc</emphasis>, <emphasis>sparc</emphasis>,
<emphasis>hurd-i386</emphasis>, <emphasis>arm</emphasis>,
<emphasis>ia64</emphasis>, <emphasis>hppa</emphasis>,
<emphasis>s390</emphasis>, <emphasis>mips</emphasis>,
<emphasis>mipsel</emphasis> and <emphasis>sh</emphasis> as of this writing.
</para>
<para>
&debian-formal; 1.3 is only available as <emphasis>i386</emphasis>.  Debian
2.0 shipped for <emphasis>i386</emphasis> and <emphasis>m68k</emphasis>
architectures.  Debian 2.1 ships for the <emphasis>i386</emphasis>,
<emphasis>m68k</emphasis>, <emphasis>alpha</emphasis>, and
<emphasis>sparc</emphasis> architectures.  Debian 2.2 added support for the
<emphasis>powerpc</emphasis> and <emphasis>arm</emphasis> architectures.
Debian 3.0 added support of five new architectures: <emphasis>ia64</emphasis>,
<emphasis>hppa</emphasis>, <emphasis>s390</emphasis>, <emphasis>mips</emphasis>
and <emphasis>mipsel</emphasis>.
</para>
<para>
Information for developers and users about the specific ports are available at
the <ulink url="&url-debian-ports;">Debian Ports web pages</ulink>.
</para>
</section>

<section id="s4.6.3">
<title>Packages</title>
<para>
There are two types of Debian packages, namely <emphasis>source</emphasis> and
<emphasis>binary</emphasis> packages.
</para>
<para>
Source packages consist of either two or three files: a
<filename>.dsc</filename> file, and either a <filename>.tar.gz</filename> file
or both an <filename>.orig.tar.gz</filename> and a
<filename>.diff.gz</filename> file.
</para>
<para>
If a package is developed specially for Debian and is not distributed outside
of Debian, there is just one <filename>.tar.gz</filename> file which contains
the sources of the program.  If a package is distributed elsewhere too, the
<filename>.orig.tar.gz</filename> file stores the so-called <emphasis>upstream
source code</emphasis>, that is the source code that's distributed by the
<emphasis>upstream maintainer</emphasis> (often the author of the software).
In this case, the <filename>.diff.gz</filename> contains the changes made by
the Debian maintainer.
</para>
<para>
The <filename>.dsc</filename> file lists all the files in the source package
together with checksums (<command>md5sums</command>) and some additional info
about the package (maintainer, version, etc.).
</para>
</section>

<section id="s4.6.4">
<title>Distributions</title>
<para>
The directory system described in the previous chapter is itself contained
within <emphasis>distribution directories</emphasis>.  Each distribution is
actually contained in the <filename>pool</filename> directory in the top-level
of the Debian archive itself.
</para>
<para>
To summarize, the Debian archive has a root directory within an FTP server.
For instance, at the mirror site, <literal>ftp.us.debian.org</literal>, the
Debian archive itself is contained in <ulink
url="ftp://ftp.us.debian.org/debian">/debian</ulink>, which is a common
location (another is <filename>/pub/debian</filename>).
</para>
<para>
A distribution comprises Debian source and binary packages, and the respective
<filename>Sources</filename> and <filename>Packages</filename> index files,
containing the header information from all those packages.  The former are kept
in the <filename>pool/</filename> directory, while the latter are kept in the
<filename>dists/</filename> directory of the archive (for backwards
compatibility).
</para>
<section id="sec-dists">
<title>Stable, testing, and unstable</title>
<para>
There are always distributions called <emphasis>stable</emphasis> (residing in
<filename>dists/stable</filename>), <emphasis>testing</emphasis> (residing in
<filename>dists/testing</filename>), and <emphasis>unstable</emphasis>
(residing in <filename>dists/unstable</filename>).  This reflects the
development process of the Debian project.
</para>
<para>
Active development is done in the <emphasis>unstable</emphasis> distribution
(that's why this distribution is sometimes called the <emphasis>development
distribution</emphasis>).  Every Debian developer can update his or her
packages in this distribution at any time.  Thus, the contents of this
distribution change from day to day.  Since no special effort is made to make
sure everything in this distribution is working properly, it is sometimes
literally unstable.
</para>
<para>
The <link linkend="testing">testing</link> distribution is generated
automatically by taking packages from unstable if they satisfy certain
criteria.  Those criteria should ensure a good quality for packages within
testing.  The update to testing is launched each day after the new packages
have been installed.  See <xref linkend="testing"/> .
</para>
<para>
After a period of development, once the release manager deems fit, the
<emphasis>testing</emphasis> distribution is frozen, meaning that the policies
which control how packages move from <emphasis>unstable</emphasis> to
<emphasis>testing</emphasis> are tightened.  Packages which are too buggy are
removed.  No changes are allowed into <emphasis>testing</emphasis> except for
bug fixes.  After some time has elapsed, depending on progress, the
<emphasis>testing</emphasis> distribution 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
<emphasis>testing</emphasis> is renamed to <emphasis>stable</emphasis>, and a
new copy is created for the new <emphasis>testing</emphasis>, and the previous
<emphasis>stable</emphasis> is renamed to <emphasis>oldstable</emphasis> and
stays there until it is finally archived.  On archiving, the contents are moved
to <literal>&archive-host;</literal>).
</para>
<para>
This development cycle is based on the assumption that the
<emphasis>unstable</emphasis> distribution becomes <emphasis>stable</emphasis>
after passing a period of being in <emphasis>testing</emphasis>.  Even once a
distribution is considered stable, a few bugs inevitably remain — that's why
the stable distribution is updated every now and then.  However, these updates
are tested very carefully and have to be introduced into the archive
individually to reduce the risk of introducing new bugs.  You can find proposed
additions to <emphasis>stable</emphasis> in the
<filename>proposed-updates</filename> directory.  Those packages in
<filename>proposed-updates</filename> that pass muster are periodically moved
as a batch into the stable distribution and the revision level of the stable
distribution is incremented (e.g., ‘3.0’ becomes ‘3.0r1’, ‘2.2r4’
becomes ‘2.2r5’, and so forth).  Please refer to
<link linkend="upload-stable">uploads to the <emphasis>stable</emphasis>
distribution</link> for details.
</para>
<para>
Note that development under <emphasis>unstable</emphasis> continues during the
freeze period, since the <emphasis>unstable</emphasis> distribution remains in
place in parallel with <emphasis>testing</emphasis>.
</para>
</section>

<section id="s4.6.4.2">
<title>More information about the testing distribution</title>
<para>
Packages are usually installed into the `testing' distribution after they have
undergone some degree of testing in unstable.
</para>
<para>
For more details, please see the <link linkend="testing">information about
the testing distribution</link>.
</para>
</section>

<section id="experimental">
<title>Experimental</title>
<para>
The <emphasis>experimental</emphasis> distribution is a special distribution.
It is not a full distribution in the same sense as `stable' and `unstable' are.
Instead, it is meant to be a temporary staging area for highly experimental
software where there's a good chance that the software could break your system,
or software that's just too unstable even for the <emphasis>unstable</emphasis>
distribution (but there is a reason to package it nevertheless).  Users who
download and install packages from <emphasis>experimental</emphasis> are
expected to have been duly warned.  In short, all bets are off for the
<emphasis>experimental</emphasis> distribution.
</para>
<para>
These are the <citerefentry> <refentrytitle>sources.list</refentrytitle>
<manvolnum>5</manvolnum> </citerefentry> lines for
<emphasis>experimental</emphasis>:
</para>
<programlisting>
deb http://ftp.<replaceable>xy</replaceable>.debian.org/debian/ experimental main
deb-src http://ftp.<replaceable>xy</replaceable>.debian.org/debian/ experimental main
</programlisting>
<para>
If there is a chance that the software could do grave damage to a system, it is
likely to be better to put it into <emphasis>experimental</emphasis>.  For
instance, an experimental compressed file system should probably go into
<emphasis>experimental</emphasis>.
</para>
<para>
Whenever there is a new upstream version of a package that introduces new
features but breaks a lot of old ones, it should either not be uploaded, or be
uploaded to <emphasis>experimental</emphasis>.  A new, beta, version of some
software which uses a completely different configuration can go into
<emphasis>experimental</emphasis>, at the maintainer's discretion.  If you are
working on an incompatible or complex upgrade situation, you can also use
<emphasis>experimental</emphasis> as a staging area, so that testers can get
early access.
</para>
<para>
Some experimental software can still go into <emphasis>unstable</emphasis>,
with a few warnings in the description, but that isn't recommended because
packages from <emphasis>unstable</emphasis> are expected to propagate to
<emphasis>testing</emphasis> and thus to <emphasis>stable</emphasis>.  You
should not be afraid to use <emphasis>experimental</emphasis> since it does not
cause any pain to the ftpmasters, the experimental packages are automatically
removed once you upload the package in <emphasis>unstable</emphasis> with a
higher version number.
</para>
<para>
New software which isn't likely to damage your system can go directly into
<emphasis>unstable</emphasis>.
</para>
<para>
An alternative to <emphasis>experimental</emphasis> is to use your personal web
space on <literal>people.debian.org</literal>.
</para>
<para>
When uploading to unstable a package which had bugs fixed in experimental,
please consider using the option <literal>-v</literal> to
<command>dpkg-buildpackage</command> to finally get them closed.
</para>
</section>

</section>

<section id="codenames">
<title>Release code names</title>
<para>
Every released Debian distribution has a <emphasis>code name</emphasis>: Debian
1.1 is called `buzz'; Debian 1.2, `rex'; Debian 1.3, `bo'; Debian 2.0, `hamm';
Debian 2.1, `slink'; Debian 2.2, `potato'; Debian 3.0, `woody'; Debian 3.1,
sarge; Debian 4.0, etch.  There is also a ``pseudo-distribution'', called
`sid', which is the current `unstable' distribution; since packages are moved
from `unstable' to `testing' as they approach stability, `sid' itself is never
released.  As well as the usual contents of a Debian distribution, `sid'
contains packages for architectures which are not yet officially supported or
released by Debian.  These architectures are planned to be integrated into the
mainstream distribution at some future date.
</para>
<para>
Since Debian has an open development model (i.e., everyone can participate and
follow the development) even the `unstable' and `testing' distributions are
distributed to the Internet through the Debian FTP and HTTP server network.
Thus, if we had called the directory which contains the release candidate
version `testing', then we would have to rename it to `stable' when the version
is released, which would cause all FTP mirrors to re-retrieve the whole
distribution (which is quite large).
</para>
<para>
On the other hand, if we called the distribution directories
<emphasis>Debian-x.y</emphasis> from the beginning, people would think that
Debian release <emphasis>x.y</emphasis> is available.  (This happened in the
past, where a CD-ROM vendor built a Debian 1.0 CD-ROM based on a pre-1.0
development version.  That's the reason why the first official Debian release
was 1.1, and not 1.0.)
</para>
<para>
Thus, the names of the distribution directories in the archive are determined
by their code names and not their release status (e.g., `slink').  These names
stay the same during the development period and after the release; symbolic
links, which can be changed easily, indicate the currently released stable
distribution.  That's why the real distribution directories use the
<emphasis>code names</emphasis>, while symbolic links for
<emphasis>stable</emphasis>, <emphasis>testing</emphasis>, and
<emphasis>unstable</emphasis> point to the appropriate release directories.
</para>
</section>

</section>

<section id="mirrors">
<title>Debian mirrors</title>
<para>
The various download archives and the web site have several mirrors available
in order to relieve our canonical servers from heavy load.  In fact, some of
the canonical servers aren't public — a first tier of mirrors balances the
load instead.  That way, users always access the mirrors and get used to using
them, which allows Debian to better spread its bandwidth requirements over
several servers and networks, and basically makes users avoid hammering on one
primary location.  Note that the first tier of mirrors is as up-to-date as it
can be since they update when triggered from the internal sites (we call this
push mirroring).
</para>
<para>
All the information on Debian mirrors, including a list of the available public
FTP/HTTP servers, can be found at <ulink
url="&url-debian-mirrors;"></ulink>.  This useful page also
includes information and tools which can be helpful if you are interested in
setting up your own mirror, either for internal or public access.
</para>
<para>
Note that mirrors are generally run by third-parties who are interested in
helping Debian.  As such, developers generally do not have accounts on these
machines.
</para>
</section>

<section id="incoming-system">
<title>The Incoming system</title>
<para>
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 on <literal>&ftp-master-host;</literal>.
</para>
<para>
Packages are uploaded by all the maintainers into a directory called
<filename>UploadQueue</filename>.  This directory is scanned every few minutes
by a daemon called <command>queued</command>,
<filename>*.command</filename>-files are executed, and remaining and correctly
signed <filename>*.changes</filename>-files are moved together with their
corresponding files to the <filename>unchecked</filename> directory.  This
directory is not visible for most Developers, as ftp-master is restricted; it
is scanned every 15 minutes by the <command>katie</command> 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 <filename>accepted</filename> directory.  If this is the first upload
of the package (or it has new binary packages), it is moved to the
<filename>new</filename> directory, where it waits for approval by the
ftpmasters.  If the package contains files to be installed by hand it is moved
to the <filename>byhand</filename> directory, where it waits for manual
installation by the ftpmasters.  Otherwise, if any error has been detected, the
package is refused and is moved to the <filename>reject</filename> directory.
</para>
<para>
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 <ulink url="&url-incoming;"></ulink> until it is really
installed in the Debian archive.  This happens only once a day (and is also
called the `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 <filename>Packages</filename> and
<filename>Sources</filename> index files for example) have been made, a special
script is called to ask all the primary mirrors to update themselves.
</para>
<para>
The archive maintenance software will also send the OpenPGP/GnuPG signed
<filename>.changes</filename> file that you uploaded to the appropriate mailing
lists.  If a package is released with the <literal>Distribution:</literal> set
to `stable', the announcement is sent to
&email-debian-changes;.  If a package is released with
<literal>Distribution:</literal> set to `unstable' or `experimental', the
announcement will be posted to &email-debian-devel-changes;
instead.
</para>
<para>
Though ftp-master is restricted, a copy of the installation is available to all
developers on <literal>&ftp-master-mirror;</literal>.
</para>
<!-- FIXME: delete it or keep it for historical purposes?
<para>
All Debian developers have write access to the <filename>unchecked</filename>
directory in order to upload their packages; they also have that access
to the <filename>reject</filename> directory in order to remove their bad uploads
or to move some files back to the <filename>unchecked</filename> directory. But
all the other directories are only writable by the ftpmasters, which is
why you cannot remove an upload once it has been accepted.
</para>

<section id="delayed-incoming-broken">
<title>Delayed incoming</title>
<para>
<emphasis>Note:</emphasis> This description here is currently not working, because
ftp-master is restricted. Please see <xref linkend="delayed-incoming"/> for
the currently working way.
</para>
<para>
The <filename>unchecked</filename> directory has a special <filename>DELAYED</filename>
subdirectory. It is itself subdivided in nine directories
called <filename>1-day</filename> to <filename>9-day</filename>. Packages which are uploaded to
one of those directories will be moved to the real unchecked
directory after the corresponding number of days.
This is done by a script which is run each day and which moves the
packages between the directories. Those which are in "1-day" are
installed in <filename>unchecked</filename> while the others are moved to the 
adjacent directory (for example, a package in <filename>5-day</filename> will
be moved to <filename>4-day</filename>). This feature is particularly useful
for people who are doing non-maintainer uploads. Instead of
waiting before uploading a NMU, it is uploaded as soon as it is
ready, but to one of those <filename>DELAYED/<varname>x</varname>-day</filename> directories.
That leaves the corresponding number of days for the maintainer
to react and upload another fix themselves if they are not
completely satisfied with the NMU. Alternatively they can remove
the NMU.
</para>
<para>
The use of that delayed feature can be simplified with a bit
of integration with your upload tool.  For instance, if you use 
<command>dupload</command> (see <xref linkend="dupload"/>), you can add this
snippet to your configuration file:
<programlisting>
$delay = ($ENV{DELAY} || 7);
$cfg{'delayed'} = {
         fqdn => "&ftp-master-host;",
         login => "yourdebianlogin",
         incoming => "/org/&ftp-debian-org;/incoming/DELAYED/$delay-day/",
         dinstall_runs => 1,
         method => "scpb"
};
</programlisting>
Once you've made that change, <command>dupload</command> can be used to
easily upload a package in one of the delayed directories:
<literal>DELAY=5 dupload -X-to delayed &lt;changes-file&gt;</literal>
</para>
</section>
-->
</section>

<section id="pkg-info">
<title>Package information</title>
<section id="pkg-info-web">
<title>On the web</title>
<para>
Each package has several dedicated web pages.
<literal>http://&packages-host;/<replaceable>package-name</replaceable></literal>
displays each version of the package available in the various distributions.
Each version links to a page which provides information, including the package
description, the dependencies, and package download links.
</para>
<para>
The bug tracking system tracks bugs for each package.  You can view the bugs of
a given package at the URL
<literal>http://&bugs-host;/<replaceable>package-name</replaceable></literal>.
</para>
</section>

<section id="madison">
<title>The <command>madison</command> utility</title>
<para>
<command>madison</command> is a command-line utility that is available on
<literal>&ftp-master-host;</literal>, and on the mirror on
<literal>&ftp-master-mirror;</literal>.  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 it better.
</para>
<screen>
$ madison libdbd-mysql-perl
libdbd-mysql-perl |   1.2202-4 |        stable | source, alpha, arm, i386, m68k, powerpc, sparc
libdbd-mysql-perl |   1.2216-2 |       testing | source, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
libdbd-mysql-perl | 1.2216-2.0.1 |       testing | alpha
libdbd-mysql-perl |   1.2219-1 |      unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
</screen>
<para>
In this example, you can see that the version in <emphasis>unstable</emphasis>
differs from the version in <emphasis>testing</emphasis> and that there has
been a binary-only NMU of the package for the alpha architecture.  Each version
of the package has been recompiled on most of the architectures.
</para>
</section>

</section>

<section id="pkg-tracking-system">
<title>The Package Tracking System</title>
<para>
The Package Tracking System (PTS) is an email-based tool to track the activity
of a source package.  This really means that you can get the same emails that
the package maintainer gets, simply by subscribing to the package in the PTS.
</para>
<para>
Each email sent through the PTS is classified under one of the keywords listed
below.  This will let you select the mails that you want to receive.
</para>
<para>
By default you will get:
</para>
<variablelist>
<varlistentry>
<term><literal>bts</literal></term>
<listitem>
<para>
All the bug reports and following discussions.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>bts-control</literal></term>
<listitem>
<para>
The email notifications from <email>control@&bugs-host;</email> about bug
report status changes.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>upload-source</literal></term>
<listitem>
<para>
The email notification from <command>katie</command> when an uploaded source
package is accepted.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>katie-other</literal></term>
<listitem>
<para>
Other warning and error emails from <command>katie</command> (such as an
override disparity for the section and/or the priority field).
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>default</literal></term>
<listitem>
<para>
Any non-automatic email sent to the PTS by people who wanted to contact the
subscribers of the package.  This can be done by sending mail to
<literal><replaceable>sourcepackage</replaceable>@&pts-host;</literal>.
In order to prevent spam, all messages sent to these addresses must contain the
<literal>X-PTS-Approved</literal> header with a non-empty value.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>summary</literal></term>
<listitem>
<para>
Regular summary emails about the package's status.  Currently, only progression
in <emphasis>testing</emphasis> is sent.
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
You can also decide to receive additional information:
</para>
<variablelist>
<varlistentry>
<term><literal>upload-binary</literal></term>
<listitem>
<para>
The email notification from <command>katie</command> when an uploaded binary
package is accepted.  In other words, whenever a build daemon or a porter
uploads your package for another architecture, you can get an email to track
how your package gets recompiled for all architectures.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>cvs</literal></term>
<listitem>
<para>
CVS commit notifications, if the package has a CVS repository and the
maintainer has set up forwarding commit notifications to the PTS.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>ddtp</literal></term>
<listitem>
<para>
Translations of descriptions or debconf templates submitted to the Debian
Description Translation Project.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>derivatives</literal></term>
<listitem>
<para>
Information about changes made to the package in derivative distributions (for
example Ubuntu).
</para>
</listitem>
</varlistentry>
</variablelist>
<section id="pts-commands">
<title>The PTS email interface</title>
<para>
You can control your subscription(s) to the PTS by sending various commands to
<email>pts@qa.debian.org</email>.
</para>
<variablelist>
<varlistentry>
<term><literal>subscribe &lt;sourcepackage&gt; [&lt;email&gt;]</literal></term>
<listitem>
<para>
Subscribes <replaceable>email</replaceable> to communications related to the
source package <replaceable>sourcepackage</replaceable>.  Sender address is
used if the second argument is not present.  If
<replaceable>sourcepackage</replaceable> is not a valid source package, you'll
get a warning.  However if it's a valid binary package, the PTS will subscribe
you to the corresponding source package.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>unsubscribe &lt;sourcepackage&gt; [&lt;email&gt;]</literal></term>
<listitem>
<para>
Removes a previous subscription to the source package
<replaceable>sourcepackage</replaceable> using the specified email address or
the sender address if the second argument is left out.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>unsubscribeall [&lt;email&gt;]</literal></term>
<listitem>
<para>
Removes all subscriptions of the specified email address or the sender address
if the second argument is left out.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>which [&lt;email&gt;]</literal></term>
<listitem>
<para>
Lists all subscriptions for the sender or the email address optionally
specified.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>keyword [&lt;email&gt;]</literal></term>
<listitem>
<para>
Tells you the keywords that you are accepting.  For an explanation of keywords,
<link linkend="pkg-tracking-system">see above</link>.  Here's a quick
summary:
</para>
<itemizedlist>
<listitem>
<para>
<literal>bts</literal>: mails coming from the Debian Bug Tracking System
</para>
</listitem>
<listitem>
<para>
<literal>bts-control</literal>: reply to mails sent to
&email-bts-control;
</para>
</listitem>
<listitem>
<para>
<literal>summary</literal>: automatic summary mails about the state of a
package
</para>
</listitem>
<listitem>
<para>
<literal>cvs</literal>: notification of CVS commits
</para>
</listitem>
<listitem>
<para>
<literal>ddtp</literal>: translations of descriptions and debconf templates
</para>
</listitem>
<listitem>
<para>
<literal>derivatives</literal>: changes made on the package by derivative
distributions
</para>
</listitem>
<listitem>
<para>
<literal>upload-source</literal>: announce of a new source upload that has been
accepted
</para>
</listitem>
<listitem>
<para>
<literal>upload-binary</literal>: announce of a new binary-only upload
(porting)
</para>
</listitem>
<listitem>
<para>
<literal>katie-other</literal>: other mails from ftpmasters (override
disparity, etc.)
</para>
</listitem>
<listitem>
<para>
<literal>default</literal>: all the other mails (those which aren't automatic)
</para>
</listitem>
</itemizedlist>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>keyword &lt;sourcepackage&gt; [&lt;email&gt;]</literal></term>
<listitem>
<para>
Same as the previous item but for the given source package, since you may
select a different set of keywords for each source package.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>keyword [&lt;email&gt;] {+|-|=} &lt;list of keywords&gt;</literal></term>
<listitem>
<para>
Accept (+) or refuse (-) mails classified under the given keyword(s).  Define
the list (=) of accepted keywords.  This changes the default set of keywords
accepted by a user.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>keywordall [&lt;email&gt;] {+|-|=} &lt;list of keywords&gt;</literal></term>
<listitem>
<para>
Accept (+) or refuse (-) mails classified under the given keyword(s).  Define
the list (=) of accepted keywords.  This changes the set of accepted keywords
of all the currently active subscriptions of a user.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>keyword &lt;sourcepackage&gt; [&lt;email&gt;] {+|-|=} &lt;list of keywords&gt;</literal></term>
<listitem>
<para>
Same as previous item but overrides the keywords list for the indicated source
package.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>quit | thanks | --</literal></term>
<listitem>
<para>
Stops processing commands.  All following lines are ignored by the bot.
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
The <command>pts-subscribe</command> command-line utility (from the <systemitem
role="package">devscripts</systemitem> package) can be handy to temporarily
subscribe to some packages, for example after having made an non-maintainer
upload.
</para>
</section>

<section id="pts-mail-filtering">
<title>Filtering PTS mails</title>
<para>
Once you are subscribed to a package, you will get the mails sent to
<literal><replaceable>sourcepackage</replaceable>@&pts-host;</literal>.
Those mails have special headers appended to let you filter them in a special
mailbox (e.g.  with <command>procmail</command>).  The added headers are
<literal>X-Loop</literal>, <literal>X-PTS-Package</literal>,
<literal>X-PTS-Keyword</literal> and <literal>X-Unsubscribe</literal>.
</para>
<para>
Here is an example of added headers for a source upload notification on the
<systemitem role="package">dpkg</systemitem> package:
</para>
<screen>
X-Loop: dpkg@&pts-host;
X-PTS-Package: dpkg
X-PTS-Keyword: upload-source
X-Unsubscribe: echo 'unsubscribe dpkg' | mail pts@qa.debian.org
</screen>
</section>

<section id="pts-cvs-commit">
<title>Forwarding CVS commits in the PTS</title>
<para>
If you use a publicly accessible CVS repository for maintaining your Debian
package, you may want to forward the commit notification to the PTS so that the
subscribers (and possible co-maintainers) can closely follow the package's
evolution.
</para>
<para>
Once you set up the CVS repository to generate commit notifications, you just
have to make sure it sends a copy of those mails to
<literal><replaceable>sourcepackage</replaceable>_cvs@&pts-host;</literal>.
Only the people who accept the <emphasis>cvs</emphasis> keyword will receive
these notifications.
</para>
</section>

<section id="pts-web">
<title>The PTS web interface</title>
<para>
The PTS has a web interface at <ulink
url="http://&pts-host;/"></ulink> that puts together a lot of
information about each source package.  It features many useful links (BTS, QA
stats, contact information, DDTP translation status, buildd logs) and gathers
much more information from various places (30 latest changelog entries, testing
status, ...).  It's a very useful tool if you want to know what's going on with
a specific source package.  Furthermore there's a form that allows easy
subscription to the PTS via email.
</para>
<para>
You can jump directly to the web page concerning a specific source package with
a URL like
<literal>http://&pts-host;/<replaceable>sourcepackage</replaceable></literal>.
</para>
<para>
This web interface has been designed like a portal for the development of
packages: you can add custom content on your packages' pages.  You can add
static information (news items that are meant to stay available indefinitely)
and news items in the latest news section.
</para>
<para>
Static news items can be used to indicate:
</para>
<itemizedlist>
<listitem>
<para>
the availability of a project hosted on
<link linkend="alioth">Alioth</link> for co-maintaining the package
</para>
</listitem>
<listitem>
<para>
a link to the upstream web site
</para>
</listitem>
<listitem>
<para>
a link to the upstream bug tracker
</para>
</listitem>
<listitem>
<para>
the existence of an IRC channel dedicated to the software
</para>
</listitem>
<listitem>
<para>
any other available resource that could be useful in the maintenance of the
package
</para>
</listitem>
</itemizedlist>
<para>
Usual news items may be used to announce that:
</para>
<itemizedlist>
<listitem>
<para>
beta packages are available for testing
</para>
</listitem>
<listitem>
<para>
final packages are expected for next week
</para>
</listitem>
<listitem>
<para>
the packaging is about to be redone from scratch
</para>
</listitem>
<listitem>
<para>
backports are available
</para>
</listitem>
<listitem>
<para>
the maintainer is on vacation (if they wish to publish this information)
</para>
</listitem>
<listitem>
<para>
a NMU is being worked on
</para>
</listitem>
<listitem>
<para>
something important will affect the package
</para>
</listitem>
</itemizedlist>
<para>
Both kinds of news are generated in a similar manner: you just have to send an
email either to <email>pts-static-news@qa.debian.org</email> or to
<email>pts-news@qa.debian.org</email>.  The mail should indicate which package
is concerned by having the name of the source package in a
<literal>X-PTS-Package</literal> mail header or in a <literal>Package</literal>
pseudo-header (like the BTS reports).  If a URL is available in the
<literal>X-PTS-Url</literal> mail header or in the <literal>Url</literal>
pseudo-header, then the result is a link to that URL instead of a complete news
item.
</para>
<para>
Here are a few examples of valid mails used to generate news items in the PTS.
The first one adds a link to the cvsweb interface of debian-cd in the Static
information section:
</para>
<screen>
From: Raphael Hertzog &lt;hertzog@debian.org&gt;
To: pts-static-news@qa.debian.org
Subject: Browse debian-cd CVS repository with cvsweb

Package: debian-cd
Url: &url-cvsweb;debian-cd/
</screen>
<para>
The second one is an announcement sent to a mailing list which is also sent to
the PTS so that it is published on the PTS web page of the package.  Note the
use of the BCC field to avoid answers sent to the PTS by mistake.
</para>
<screen>
: Raphael Hertzog &lt;hertzog@debian.org&gt;
To: debian-gtk-gnome@&lists-host;
Bcc: pts-news@qa.debian.org
Subject: Galeon 2.0 backported for woody
X-PTS-Package: galeon

Hello gnomers!

I'm glad to announce that galeon has been backported for woody. You'll find
everything here:
...
</screen>
<para>
Think twice before adding a news item to the PTS because you won't be able 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.
</para>
</section>

</section>

<section id="ddpo">
<title>Developer's packages overview</title>
<para>
A QA (quality assurance) web portal is available at <ulink
url="&url-ddpo;"></ulink> which displays a table listing all
the packages of a single developer (including those where the party is listed
as a co-maintainer).  The table gives a good summary about the developer's
packages: number of bugs by severity, list of available versions in each
distribution, testing status and much more including links to any other useful
information.
</para>
<para>
It is a good idea to look up your own data regularly so that you don't forget
any open bugs, and so that you don't forget which packages are your
responsibility.
</para>
</section>

<section id="alioth">
<title>Debian *Forge: Alioth</title>
<para>
Alioth is a fairly new Debian service, based on a slightly modified version of
the GForge software (which evolved from SourceForge).  This software offers
developers access to easy-to-use tools such as bug trackers, patch manager,
project/task managers, file hosting services, mailing lists, CVS repositories
etc.  All these tools are managed via a web interface.
</para>
<para>
It is intended to provide facilities to free software projects backed or led by
Debian, facilitate contributions from external developers to projects started
by Debian, and help projects whose goals are the promotion of Debian or its
derivatives.
</para>
<para>
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.
</para>
<para>
For more information please visit <ulink
url="&url-alioth;"></ulink>.
</para>
</section>

<section id="developer-misc">
<title>Goodies for Developers</title>
<section id="lwn">
<title>LWN Subscriptions</title>
<para>
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 <ulink
url="http://&lists-host;/debian-devel-announce/2002/10/msg00018.html"></ulink>.
</para>
</section>

</section>

</chapter>