Standards for QA uploads?
I was just working through QA procedures with my NM applicant, and I
realised that it's not immediately obvious what the standards are for making
a QA upload. A quick flick through the list archives with google didn't
reveal anything particularly enlightening, and none of the links at
qa.debian.org appear to detail how things should be done.
So, in the interest of good housekeeping, I present the following list as a
starting point to producing a "QA upload best practices" guide. Hopefully
we'll all get in and refine it down to something useful, then someone with
write access to the site will put it in an appropriate location.
I've put my commentary and rationale in [square brackets] so others know
what I was smoking when I thought these up. I don't expect they'll go into
the final document.
-------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.
* 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.]
* In most aspects of preparing a QA upload, follow NMU policy. Things like
ensuring your changes are as minimal as possible, and thoroughly testing
your changes, 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.
* After you make your upload, subscribe to the package's PTS entry to watch
for any bug reports which might come in as a result of your new upload.
----->8------
Discussion, anyone?
- Matt
Reply to: