Documentation for Patch Queue Manager

Jeff Licquia jeff at licquia.org
Sun Oct 14 09:18:12 BST 2007


Ben Finney wrote:
> No responses to this so far, so I'll be more explicit about my goals
> in the hope that someone can help me before my deadline expires.

Hi, Ben.  I've had the opportunity to deploy PQM, so maybe I can help. 
I don't know how helpful I can be in regards to Mercurial, since it's 
been a year since I looked at it, but I can at least tell you about my 
experiences on the bzr side.

> I can clearly demonstrate that the first few steps are equally simple
> with Bazaar. Where I fall short is pointing to Bazaar's support for
> repository hooks and commit actions. Both of us want Bazaar to be the
> right choice, but currently it seems Mercurial has this support simply
> and Bazaar doesn't. We'd both like to be proved wrong.

Bzr itself has post-commit hooks, but I'm not sure they would help you. 
  In particular, they're post-commit, which may have implications for 
bound branches.  Plus, to use them, you basically have to write a plugin 
that does what you want, and then point the post-commit hook at the 
function in the plugin.

> My vague impression is that PQM is part of the answer, but, as this
> thread points out in its initial message, it seems to be vastly
> under-documented, so we can't get very far figuring out PQM, and if
> it's very difficult it will still compare poorly to Mercurial.

The best documentation for PQM is in the source itself--not the source 
itself, but the README and manual shipped in the source.  This should be 
put on the web so it's easy to find, definitely.

I've found that the biggest hassle with PQM was setting up 
config-manager, an external resource PQM uses.  Also, PQM really wants 
to operate via E-mail.  In our case (the Linux Foundation case, to be 
specific), we wanted it to work on the web, so we had to write some 
infrastructure to do that.  The docs describe how to do something like 
that (by focusing on command-line submission).  If PQM could be taught 
how to read merge directives directly, this would become a lot easier.

To do the specific hooks, you set the pre-commit command in the PQM 
config file:

> # an external command to allow/disallow commits.
> # Return non-zero to signal error.
> #precommit_hook=foo-bar.sh param1 param2

I don't know how Mercurial implements this stuff, so I can't say whether 
PQM is better or not.  Were I in your shoes, I might try to find the 
answer to these questions for the Mercurial solution:

  - Is the hook asynchronous?  If users have to wait for a test suite to 
finish before their commit command exits, I predict the users will 
revolt at some point.  Of course, PQM is asynchronous.

  - How do you enforce workflow?  IMHO, this needs some purely 
server-side support.  Distributed VC makes this fairly easy with simple 
branching, but you have to manage how merges to the "official branch" 
happen.  If that happens on the client side, you know impatient 
developers will be tempted to find a way to bypass it.  Ditto if the 
process isn't client-side, but is manually followed by a project lead of 
some sort.  ("Oops!  Forgot 'make test' before merging; hope there 
wasn't anything there...")  PQM is basically an infrastructure for 
async, server-side automatic management of the workflow.

Don't forget, too, the utility of add-ons like Bundle Buggy.




More information about the bazaar mailing list