• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

PQM Message Style Guide

[Are these really different from merge proposal cover letters? If they can be the same thing, then we should merge the two pages, and come up with a canonical name for them: "cover letter", "merge message", "PQM message", or whatever, to distinguish from "commit message", which is per-commit. -kff]

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] <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. For each bug, include the bug number and the bug summary next to it. e.g. "Fixes: bug 12345: Mozilla Firefox lacks SVG support; bug 54321: Lack of spacing in new account form."
5. Include names of specs implemented in this landing. e.g, "Implements Native-XPI-Imports."

Note: URLs to the full bug record can be very helpful but the above format has really overshadowed their inclusion considerably because of the time it saves rewriting the PQM messages into a publicly readable changelog.

Examples

• 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. Fixes bug 121348: BugZilla VERIFIED WONTFIX should map to Won't Fix; bug 113974: upstream linking does not know about code_fix.

• 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. Fixes bug 90791: Anonymous users cause OOPS when nominating.

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

• It is now possible to register blueprints directly from project group pages. While looking at a project group page, select "register a blueprint" from the actions panel. Implements register-blueprints-from-project-groups.

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.