launchpad development
Quality Assurance: Verifying Changes to Launchpad
This page describes how to get changes to Launchpad verified ("QA'd") before they are released. |
When a new change lands Launchpad, the change isn't finished yet -- it still needs to be QA'd.
First, the author of the change should have already described the QA procedure in the merge proposal cover letter. The ideal QA procedure is runnable by any Launchpad user, not just developers. It's best if a change can be QA'd using edge or staging, not a local launchpad.dev development instance (see Barry Warsaw's mail about this). This should be the case for most changes, though there are occasional exceptions.
Next, the author needs to find someone to actually do that QA...
How to Get QA for a Change
People are willing to do QA, but generally need to be asked to do it for a specific change -- consider that request to be part of finishing the change. Volunteers rarely show up on their own initiative looking for random changes to QA; instead, the author of a change needs to find people and explicitly request them to QA it.
The best way to find them is to look at the discussion around the fix, especially in the bug or mailing list thread that preceded the fix. Are there people who made comments, or who said that they were looking forward to the improvement in question? If so, they could be asked to QA it, and to send their feedback in the same forum (and if they can update the #pending-qa pending QA wiki page, that's even better).
If there are no obvious candidates to QA a change, the author should go into IRC (#launchpad-dev IRC channel at irc.freenode.net) and try to find someone there. If no takers, it's fine to try the user forum (#launchpad) too, and then try posting on launchpad-dev@ or launchpad-users@. The subject line of the mail should specify the nature of the change being QA'd, so people interested in that change are likely to see it (and so everyone else can skip it).
Listing Changes That Still Need QA
Prior to any release or milestone, there is always a list of changes needing QA. For example, here is the list of changes needing QA leading up to the 2.2.8 milestone.
Once someone has tested a change, they should move it to the "OK" or "BAD" section on that page as appropriate, and follow up with the original author and/or in a bug or mailing list thread as appropriate. If you know a change has been tested (because you saw discussion elsewhere about it), please just update the QA page as needed, based on that discussion.
