I've incorporated the excellent suggestions from Pierre Machard, Andreas Metzler, and Frank Lichtenheld, to produce this new draft. Further comments appreciated.
-----8<----- QA UPLOAD BEST PRACTICES When making an upload on a package maintained by the QA team, it is important to keep some basic points in mind to ensure that these packages are kept in good order while they wait for a new maintainer. Consistency is a valuable commodity. * If you're going to be working on a QA upload for a while, notify debian-qa@lists.debian.org, and probably the bug reports you're hacking on, of your intentions. This minimises duplicated work, and helps people know what's going on. Setting the owner of the bug to you (not the submitter!) is a useful marker to other people who might be interested. * It is useful to note that the upload you are making is a QA one in the changelog, for future reference. Something like "* QA Upload" as the first item in the changelog is sufficient. * Packages "maintained" by the QA team don't have a real maintainer, therefore nobody can do a real "maintainer upload". Hence there is no point differentiating NMUs, so don't use NMU version numbering for your uploads. [To be practical, every DD is a potential QA team member, and is therefore the co-maintainer for orphaned packages. And a very long string of NMU version numbers is ugly, especially when new upstream versions are packaged by QA.] * It's also important to ensure that the maintainer address is set correctly. The address has changed in the past, and some packages haven't had their maintainer address changed since it's orphaning (even after several QA uploads!), so ensure that the maintainer of the package is set to "Debian QA Packages <[EMAIL PROTECTED]>". * In most aspects of preparing a QA upload, follow NMU policy. Things like ensuring your changes are as minimal as possible, and testing your changes extra carefully, is very important. Since you're not the regular maintainer, you probably won't understand what's being done as thoroughly as you would for your own packages, so ensure you're not subtly breaking something with your changes. There are some things that you should do in a QA upload that you wouldn't do in an NMU, however. Fixing minor bugs, for instance, something that normally isn't done in an NMU, is encouraged. Typos, improving the package's description, keeping the standards-version current, and other "housekeeping" tasks, are all good things to do in a QA upload. New upstream versions, also, are not discouraged as they are with an NMU. * After you make your upload, ensure that you monitor the package for a while so you can fix any bugs which might have inadvertently been introduced by your upload. You can try and remember to check the package's bugs page, but it's better to subscribe to the package's PTS entry to watch for any bug reports which might come in as a result of your new upload. If the package is correctly orphaned (the maintainer field is set properly), you can also get bug information for the package by subscribing to the mailing list [EMAIL PROTECTED] That list gets information for all QA's packages, though, so it might not be the best option if you only want to track your one upload. ----->8-----
