Roles and responsibilities of the FTPmaster team.
Last year, the DPL asked me to look into writing descriptions of what
various teams in Debian were responsible for, and what their day to day
activity involved. I performed some interviews at the time, and then
promptly failed to get around to writing them up. The current discussion
has prompted me to finish off the writeup of the ftpmaster document, and
I intend to produce some more in the near future.
The roles and responsibilities of the ftpmaster team
----------------------------------------------------
Running the archive
-------------------
The FTP masters are responsible for maintaining the infrastructure
required to support the archive. This takes the form of the scripts used
for processing uploaded packages, but also the flow of packages between
distributions.
One thing that the FTP masters are explicitly not responsible for is the
maintenance of the mirror network. This is handled by the mirror team.
Supporting the Release Managers
-------------------------------
While the FTP masters do not determine policy for the flow of packages
from unstable to testing, they are responsible for the maintenance of
the scripts that control the process. This work is performed in close
consultation with the release managers. Similarly, the FTP masters do
not determine which packages should make up stable point releases -
however, they are responsible for ensuring that the packages move into
stable correctly.
Of course, the FTP masters are also responsible for the final movement
of packages from testing into stable at the time of release, following
the instructions of the release managers.
Accepting and rejecting packages
--------------------------------
When a package is uploaded, it falls into one of three categories. If it
is a new version of an existing package and adds no new binary packages,
it is moved into the accepted queue automatically. If one or more of the
binary packages is not currently in the archive, it is NEW and must be
examined by an FTP master. Finally, some uploads are not traditional
Debian packages (installer images, for example) and are classified as
byhand to indicate that they require manual processing. In the case of
the upload failing basic checks, it will be rejected.
Packages that are moved into NEW are added to a queue. The contents of
the queue are mailed to the FTP masters, along with information about
the packages. This allows them to check the copyright of the package and
ensure that the package meets certain basic levels of correctness.
However, it is not their responsibility to ensure that the package is
free of release critical bugs - it's expected that the maintainer has
done so. In the case of the package potentially leaving Debian liable to
lawsuits, it is unlikely to be accepted.
Manual NEW checking is required in order to ensure that uploaded
packages meet certain basic standards. In the absence of the NEW check,
it would be much easier for packages with legal issues or those with
gross packaging defects to enter the main Debian archive.
Once a decision has been made about the package, the FTP masters will
either reject (in the case of an obvious fault with the package) or
accept the package. Once a day (and perhaps more often in future), the
accepted packages (that is, packages that moved straight into accepted
and those that went through NEW first) are copied into the archive. They
are then distributed across the mirrors as they resync themselves.
Maintaining the state of packages and the archive
-------------------------------------------------
The FTP masters have the opportunity to alter the priority and section
of the package at any time. This information is stored in the overrides
file, which in turn is used to generate the packages file in the
archive. Historically, this was required because packages did not
contain priority and section information. Nowadays this allows a greater
level of consistency in package placement, and is most useful when new
sections (and, in theory, new priorities) are created.
Package removal is also important. This falls into two classes - binary
packages that are no longer required because the source package no
longer builds them, and requests for removals of packages. The archive
is regularly scanned for binary packages that are no longer built or
which are otherwise unnecessary, and the results mailed to the FTP
masters. After checking that this is intended, an FTP master will then
remove the package. This output can be seen at
http://ftp-master.debian.org/rene-daily.txt .
The standard way to request removal of a package is to file a bug
against ftp.debian.org. This may be because of difficulties with the
package license, because the maintainer no longer wishes the package to
be in Debian or because there are legal issues associated with the
package. In this case, the FTP masters must manually remove the package
and close the bug.
Summary
-------
Overall, the FTP masters accept responsibility for allowing new packages
to enter Debian, removing old ones and ensuring that the archive
contains the correct packages in the correct place. While much of this
work is automated, it still requires a large amount of vigilance, as
well as effort to update the tools as the needs of the project change.
--
Matthew Garrett | mjg59@srcf.ucam.org
Reply to: