Wiki Tools

  • Find Page
  • Recent Changes
  • Page History
  • Attachments

Differences between revisions 53 and 55 (spanning 2 versions)
Revision 53 as of 2011-04-15 05:18:45
Size: 3626
Editor: mbp
Comment: link to active-reviews page; emphasize the important bits
Revision 55 as of 2011-05-27 09:08:51
Size: 3759
Editor: vila
Comment: Backing up jelmer, adding more rotations. Check your availability please !
Deletions are marked like this. Additions are marked like this.
Line 38: Line 38:
|| 4 Apr w14 || spiv ||
|| 11 Apr w15 || poolie ||
|| 18 Apr w16 || jelmer ||
|| 25 Apr w17 || jam ||
|| 2 May w18 || vila ||
|| 09 May w19 || spiv ||
|| 16 May w20 || poolie ||
|| 23 May w21 || vila ||
|| 30 May w22 || jam ||
|| 06 Jun w23 || vila ||
|| 13 Jun w24 || spiv ||
|| 20 Jun w25 || poolie ||
|| 27 Jun w26 || jelmer ||
|| 03 Jul w27 || jam ||
|| 10 Jul w28 || vila ||

PatchPilot is the Bazaar community scheme to ensure that patches are not ignored or lost in traffic. When people want to improve something in Bazaar, we help them get their patch up to the right standard to land it.

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

The word pilot is in the sense of a maritime pilot: we help patches come through congested waters safely in to harbor.

Tips for pilots:

  • The main thing to watch is the bzr active reviews page in Launchpad

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

  • The recommended way to send approved patches to PQM is using the feed-pqm script from

We started 14 November 2009.



09 May w19


16 May w20


23 May w21


30 May w22


06 Jun w23


13 Jun w24


20 Jun w25


27 Jun w26


03 Jul w27


10 Jul w28


See also: