Wiki Tools

  • Find Page
  • Recent Changes
  • Page History
  • Attachments

Differences between revisions 14 and 16 (spanning 2 versions)
Revision 14 as of 2010-01-27 06:02:14
Size: 3858
Comment: added Ian C for this week
Revision 16 as of 2010-02-05 12:11:06
Size: 3935
Editor: mbp
Deletions are marked like this. Additions are marked like this.
Line 51: Line 51:
|| 1 Feb || || || 1 Feb || Vincent Ladeuil ||
|| 8 Feb || Vincent Ladeuil ||
|| 15 Feb || Martin Pool ||

PatchPilot is the Bazaar community scheme to ensure that patches are not ignored or lost in traffic.

We have a volunteer roster of committers willing to mentor and assist patches to be accepted into bzr.

Our contribution guidelines can be daunting, and patch pilots help people navigate them.

The current pilot is listed in the IRC channel topic of #bzr on irc.freenode.or for easy reference.

Roster - just put your name in here to select a week. Remember that this is a volunteer program, so its success depends on your contributions.

Tips for pilots:

  • When you're piloting, put some concentrated effort into helping people have a good and satisfying experience contributing to Bazaar. Just how you do that is up to you.
  • Send a brief mail before and/or after your stint, to say what you're going to do or what you did, and how it worked out. If you have feedback on the review system or the process, speak up.
  • You're not obliged to deal with all the open patches. We appreciate what you do do.
  • You can prioritize whichever you think best achieves the goal of helping people enjoy getting things done in Bazaar. That might be the newest ones, neglected patches, easy patches, or those from new contributors.
  • You can also choose to pick up patches and get them in yourself, by writing tests or fixing things up, or to teach/ask/encourage the original submitter to do these things. Do try to at least explain to the contributor what you're going to do.
  • You can ask (cajole) others to do reviews.
  • You can keep working on patches you're involved with when your stint ends, or you can let the next pilot pick them up. Either way, communicate.
  • If someone's already been asked to do particular changes to get a patch landed, don't move the goalposts without a very good reason.
  • Check that the contributors have executed the Canonical contributor agreement. You can do this automatically using the scan-merge-proposals script from Hydrazine or just by checking their membership of ~contributor-agreement-canonical through the web ui.

  • It's good to get to a specific outcome, so that people know what to do next, and to make this clear in both the text and formal status of the merge proposal. That might be: needs X specific fixes, needs Y tests, needs another review, just needs to be merged.
  • You can also keep an eye on work in progress merges and in progress bugs: these don't currently need review but do represent unfinished work.

  • To submit a remote branch to PQM: bzr pqm-submit --ignore-local --submit-branch= --public-location=BRANCH_URL. This requires pqm_email to be defined in the global or location configs, e.g.

    pqm_email = Canonical PQM <>



14 Nov

Andrew Bennetts

21 Nov

Robert Collins

28 Nov

Martin Pool

5 Dec

Vincent Ladeuil

12 Dec

Vincent Ladeuil

21 Dec

Martin Pool

4 Jan

Andrew Bennetts

11 Jan

John Arbash Meinel

18 Jan

Vincent Ladeuil

25 Jan

Ian Clatworthy

1 Feb

Vincent Ladeuil

8 Feb

Vincent Ladeuil

15 Feb

Martin Pool