The FTP Team
There are 3 roles in the ftpmaster team: "FTP master", "FTP Assistant", and "FTP Trainee". The people that are currently assigned to one of those roles are listed (with the exception of the trainees) at the FTP Team website and at the Debian's Organizational Structure page. The FTP masters can do everything in the archive. The assistants are limited to NEW processing, removals and override changes. The trainees can only add notes to packages in the NEW queue.
Host: fasolo.debian.org with the aliases ftp-master.debian.org and incoming.debian.org
Code repository: https://salsa.debian.org/ftp-team
- Ftpmaster: 802 (debadmin)
- Ftpteam: 1217 (ftpteam)
- Ftptrainees: 1247 (ftptrainee)
- Services handled by the team:
/srv/ftp-master.debian.org/ on ftp-master.debian.org, aka the main copy of the Debian archive as well as its copy on mirror.ftp-master.debian.org
- /srv/ftp.debian.org/ on ftp-master.debian.org
- /srv/incoming.debian.org/ on incoming.debian.org
- Various upload queues on .debian.org hosts, for example ssh.upload.debian.org.
Interacting with the team
Email contact: <email@example.com>
Request tracker: https://bugs.debian.org/ftp.debian.org (pseudo package)
Public IRC channel: #debian-ftp on irc.debian.org (OFTC)
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.
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
The FTP masters do not determine policy for the flow of packages from unstable to testing, nor they run the scripts that control the process. 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/are available in the various releases correctly (as defined by the Release Managers).
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 to the unstable or experimental suite, 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 package pool automatically. If one or more of the binary packages or the source package itself is not currently in the archive or if a package is moved between the components (main, contrib, non-free), it is NEW and must be examined by an FTP Team member (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 daily to the FTP Team members, along with information about the packages. This queue also has a webpage. 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 Team will either reject (in the case of an obvious fault with the package) or accept the package. Four times a day (see count-down), the archive is updated to reflect the new packages. Then the changes are distributed across the mirrors.
Maintaining the state of packages and the archive
The FTP Team members have the opportunity to alter the priority and section of binary packages 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 are mailed daily to the FTP Team. After checking that this is intended, FTP Team members will then remove the package.
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 Team members must manually remove the package.
Maintaining the Debian Archive Kit
FTP Team is the primary maintainer of the Debian Archive Kit (dak). The main git repository is available at https://salsa.debian.org/ftp-team/dak . Since git is a distributed version control system, everybody can contribute easily to dak. The development is coordinated via the debian-dak mailing list.
Overall, the FTP Team accepts 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.
If you know python you can also be of great help by contributing with patches to the dak code. Ftpmaster do like to merge patches!
Ever wanted to have your pet feature in dak? Go and code it! (Well, write us first, to avoid double work or running in the totally wrong direction. Nobody likes to have to redo everything because the start was wrong). If you want to help out coding, our git repository is at https://salsa.debian.org/ftp-team/dak
2005-02, on debian-project - Roles and responsibilities of the FTPmaster team
2008-05, on debian-devel-announce - Bits from the FTP Master
2009-01, on debian-devel-announce - ftpmaster profils
2009-11, on debian-devel-announce - Bits from the ftp-team
2009-11, on debian-devel-announce - Bits from the FTP Master
2010-03, on debian-devel-announce - Bits from the FTP Master
2010-06, on debian-devel-announce - moving to archive.debian.org
2010-07, on debian-devel-announce - ftp-master/release move
2010-09, on debian-devel-announce - FTPMaster meeting, step1
2010-09, on debian-project - FTPMaster meeting, minutes
2013-07, on FTPTeam changes