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 | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]