[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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.


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: