PunjabiJanta.com PunjabiTube YouTube Searcher

dbdvrf #30 Debian Developer's Reference

http://packages.debian.org/sid/developers-reference - - source in order to get them to compile for their target architecture; that would be considered a source NMU rather than a binary-only NMU. As you can see, we don't distinguish in terminology between porter NMUs and non-porter NMUs. Both classes of NMUs, source and binary-only, can be lumped under the term ``NMU''. However, this often leads to confusion, since most people think ``source NMU'' when they think ``NMU''. So it's best to be careful: always use ``binary NMU'' or ``binNMU'' for binary-only NMUs. 5.12. Collaborative maintenance Collaborative maintenance is a term describing the sharing of Debian package maintenance duties by several people. This collaboration is almost always a good idea, since it generally results in higher quality and faster bug fix turnaround times. It is strongly recommended that packages with a priority of Standard or which are part of the base set have co-maintainers. Generally there is a primary maintainer and one or more co-maintainers. The primary maintainer is the person whose name is listed in the Maintainer field of the debian/control file. Co-maintainers are all the other maintainers, usually listed in the Uploaders field of the debian/control file. In its most basic form, the process of adding a new co-maintainer is quite easy: * Setup the co-maintainer with access to the sources you build the package from. Generally this implies you are using a network-capable version control system, such as CVS or Subversion. Alioth (see Section 4.12, Debian's GForge installation: Alioth ) provides such tools, amongst others. * Add the co-maintainer's correct maintainer name and address to the Uploaders field in the first paragraph of the debian/ control file. Uploaders: John Buzz [jbuzz@debian.org], Adam Rex [arex@debian.org] * Using the PTS (Section 4.10, The Package Tracking System ), the co-maintainers should subscribe themselves to the appropriate source package. Another form of collaborative maintenance is team maintenance, which is recommended if you maintain several packages with the same group of developers. In that case, the Maintainer and Uploaders field of each package must be managed with care. It isrecommended to choose between one of the two following schemes: 1. Put the team member mainly responsible for the package in the Maintainer field. In the Uploaders, put the mailing list address, and the team members who care for the package. 2. Put the mailing list address in the Maintainer field. In the Uploaders field, put the team members who care for the package. In this case, you must make sure the mailing list accept bug reports without any human interaction (like moderation for non-subscribers). In any case, it is a bad idea to automatically put all team members in the Uploaders field. It clutters the Developer's Package Overview listing (see Section 4.11, Developer's packages overview ) with packages one doesn't really care for, and creates a false sense of good maintenance. 5.13. The testing distribution 5.13.1. Basics Packages are usually installed into the testing distribution after they have undergone some degree of testing in unstable. They must be in sync on all architectures and mustn't have dependencies that make them uninstallable; they also have to have generally no known release-critical bugs at the time they're installed into testing . This way, testing should always be close to being a release candidate. Please see below for details. 5.13.2. Updates from unstable The scripts that update the testing distribution are run twice each day, right after the installation of the updated packages; these scripts are called britney. They generate the Packages files for the testing distribution, but they do so in an intelligent manner; they try to avoid any inconsistency and to use only non-buggy packages. The inclusion of a package from unstable is conditional on the following: * The package must have been available in unstable for 2, 5 or 10 days, depending on the urgency (high, medium or low). Please note that the urgency is sticky, meaning that the highest urgency uploaded since the previous testing transition is taken into account. Those delays may be doubled during a freeze, or testing transitions may be switched off altogether; * It must not have new release-critical bugs (RC bugs affecting the version available in unstable, but not affecting the version in testing); * It must be available on all architectures on which it has previously been built in unstable. Section 4.9.2, The dak ls utility may be of interest to check that information; * It must not break any dependency of a package which is already available in testing; * The packages on which