QA Upload best practices, 2nd draft
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 <packages@qa.debian.org>".
* 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
debian-qa-packages@lists.debian.org. 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-----
Reply to: