Differences between revisions 13 and 14
Revision 13 as of 2009-01-18 09:33:29
Size: 7845
Editor: FranklinPiat
Comment: improve "Services handled by the team"
Revision 14 as of 2009-01-18 11:23:08
Size: 7841
Editor: FranklinPiat
Comment: disntasll.html -> s/faw/joerg/
Deletions are marked like this. Additions are marked like this.
Line 87: Line 87:
accept the package. [http://lists.debian.org/debian-devel/2008/12/msg00955.html Four] times a day (see [http://people.debian.org/~faw/tools/dinstall.html count-down]), the accept the package. [http://lists.debian.org/debian-devel/2008/12/msg00955.html Four] times a day (see [http://people.debian.org/~joerg/dinstall.html count-down]), the

FtpMaster

Ftp-master team is also known as Ftpteam.

Infrastructure

Interacting with the team

Usual roles

Task description

This team, commonly referred to as "ftpmaster" (a bit of a misnomer since the role is largely the same regardless of the network protocol used to obtain Debian packages from official archives), oversees and maintains the well-being of Debian's official package repositories.

  • /!\ This was not written nor reviewed by the ftpmaster team, so the content may be out of date, or completely wrong. (thanks Matthew Garrett).

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 (see NewQueue). 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. [http://lists.debian.org/debian-devel/2008/12/msg00955.html Four] times a day (see [http://people.debian.org/~joerg/dinstall.html count-down]), 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/~jeroen/rene-full.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.

Get involved

  • ?Icon(star_on.png)?Icon(star_on.png)?Icon(star_on.png) If you know python you can also be of great help by contributing with patches to the dak code. I do like to merge patches!

  • ?Icon(star_on.png)?Icon(star_on.png)?Icon(star_on.png) Ever wanted to have your pet feature in dak? Go and code it! (Well, join #debian-dak on irc.debian.org and talk to us first, to avoid double work or running in the totally wrong direction. Noone likes to have to redo everything because the start was wrong). If you want to help out coding, our git repository is at https://ftp-master.debian.org/git/dak.git

News