Not logged in - Log In / Register

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

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."



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)