Diff for "PQMCommitMessages"

Not logged in - Log In / Register

Differences between revisions 4 and 5
Revision 4 as of 2010-08-04 18:18:33
Size: 2864
Editor: bac
Comment:
Revision 5 as of 2010-08-04 22:22:02
Size: 3154
Editor: jcsackett
Comment: Added short block on the commit header [r=][ui=][bug=].
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:

Good PQM commit messages begin with a header of [r=$REVIEWER][ui=$UIREVIEW][bug=$BUGS]. So if [[https://edge.launchpad.net/~sinzui|sinzui]] reviewed your merge, you didn't have ui review, and the bugs involved were 1234 and 5678, your header would be [r=sinzui][ui=none][bug=1234,5678].

PQM Message Style Guide

This is a short guide to writing useful PQM messages. PQM messages are used to create the changelog/release notes which are published to the user community. By spending an extra minute crafting a good message, you can save the creator of the release notes up to 20 minutes or more.

Writing Good PQM Messages

Good PQM commit messages begin with a header of [r=$REVIEWER][ui=$UIREVIEW][bug=$BUGS]. So if sinzui reviewed your merge, you didn't have ui review, and the bugs involved were 1234 and 5678, your header would be [r=sinzui][ui=none][bug=1234,5678].

The following are examples of what to write, in order, after bzr pqm-submit -m "[r=Spock][ui=uhuru][bug=1701] <text below>

  1. Describe what impact the change will have on users. What will the users notice? e.g.
    • "Users now can X"
    • "It is no longer possible to do Y"
    • "The text on the ABC form is now Z" (e.g. "reworded to be gender neutral")
  2. If the above isn't clear enough for "Joe User" to understand, explaining the background to the change can be helpful, by adding in "Previously, X used to do Y". For example:
    • "Previously, users were unable to upload files to a PPA if they had zero karma."
  3. Adding an example URL for new features is good. If you don't, chances are the creator of the release notes will ping you for one.
  4. Include bugs fixed in this landing using the [bug=bugno] PQM directive. You may supply a comma-separated list of Launchpad bug numbers.
  5. Include names of specs implemented in this landing. e.g, "Implements Native-XPI-Imports."

Examples

  • [r=gmb][ui=none][bug=121348,113974] The BugZilla resolutions 'CODE_FIX' and 'PATCH_ALREADY_AVAILABLE' (for bugs of status CLOSED, VERIFIED or RESOLVED in BugZilla) are now mapped to the Launchpad 'Fix released' bug status. Bugzilla's 'WONTFIX' resolution now correctly maps to Launchpad's 'Won't Fix' status. Previously, these resolutions were incorrectly mapped to Launchpad's 'Invalid' status.'

  • [r=sinzui][ui=rockstar][[bug=90791] Anonymous users may no longer nominate a bug for release and will be asked to log in when they attempt to do so. Previously, anonymous users trying to nominate a bug for release would trigger an application error. "

  • [r=bigjools][ui=none][bug=none] There is a new page that shows a branch's associated bugs, blueprints and subscribers. Implements branch-associations-view. See https://code.launchpad.net/~ubuntu-doc/ubuntu-doc/trunk/+associations for an example.

Warnings

Note that because the -m message ends up in the Subject: header, it's possible that really long pqm-submit messages could bounce, get truncated, discarded, spam caught, or whatever, depending on the end-recipient's mail server's policies.

RFC 2822 puts an upper limit (i.e. "MUST be no more than") 998 characters and a soft limit ("SHOULD be no more than") of 78 characters. Not to say that PQM couldn't continue the Subject header across multiple lines of course.

PQMCommitMessages (last edited 2012-04-10 00:48:14 by cjwatson)