pqm for bzr development

John A Meinel john at arbash-meinel.com
Mon Oct 31 21:27:11 GMT 2005


Martin Pool wrote:
> I'd like to give more committers the ability to commit into bzr.dev.
> 
> pqm is a "patch queue manager", a process tool originally written (by
> Colin Walters?) for Arch and now ported by Robert to bazaar and
> bazaar-ng.  It's a robot that does merges between branches in response
> to user commands and can enforce policy such as making sure that tests
> run before code merges into a particular branch.
> 
> I suggest we start using pqm for merges onto the main bzr.dev branch,
> rather than me doing them by hand.  This should unblock other
> developers who have things to merge in, and free up my time.  (It's
> not so much that the changes themself take a long time, but rather the
> latency in me coming to merge them.)

I think it would be nice to use a pqm. I haven't used one yet, never
having had commit rights to the bazaar tree.

Before we start that, I would like to see a nice howto for setting up
gpg signatures. I believe Robert mentioned once "do this, and it will
work", but it was some entry in a config file, that I don't remember.
And I have a feeling there was a little bit more to it.

It would also be nice if we could get the bzr.dev tree signed for all
the revisions that people have committed. (So Martin signs all the
mbp at ... revisions, I'll sign the john at ... revisions, etc.)
We really only have to do it once, then we can just copy those
signatures around, and have everyone enable automatic signatures on commit.

> 
> pqm takes gpg-signed email as instructions to do a merge from a
> published branch into the pqm-maintained branch.  I can imagine
> improving this to use a 'bzr submit' command or to periodically
> automatically merge from a ready-to-merge branch, but we can do that
> later.
> 
> Anyone who has pqm access should feel free to pick up patches to the
> list and merge them in.  Please followup to the list so we can see
> that's been done.
> 
> There are a fair number of things where we don't all agree on the
> right way to proceed.  If there's a change that seems controversial,
> large or risky then it'd be better to post the branch or diff to the
> list first for review.  This applies to me too.  One benefit of this
> would be for me to have my own development branch more distinct from
> bzr.dev.

What ever happened to the idea of voting before the pqm does the final
merge. So that you can submit the changes, the pqm can make sure it
actually does merge, and tests pass, but doesn't commit it until you
have at least 2 developers sign off on the change. That might be too
much effort, but it seemed like a decent way to make sure controversial
patches get discussed. (There should be a way that a single developer
can flag a commit for a full vote).

I suppose for now we can just play nicely, since we do generally get along.

> 
> We've been doing pretty well on adding tests for new features and
> bugfixes, and I think continuing to do this is very important for
> people committing directly.  Robert and I have been following the
> test-driven-development rule of writing and running tests first before
> writing code (to check they fail), and I recommend this way of
> working.  If there's a change which you can't work out how to test
> then try bouncing it off people on the list or #bzr.

Were you thinking to make the pqm require a test before it will merge
things? Or just have it be good habit?

> 
> We should have pqm send out mail when it does a merge so they can be
> post-reviewed.
> 
> To start with I'd give commit to me, robertc, aaron, john and
> alexander, and expand that as needed.
> 
> How does that sound?

Overall, it sounds great to me.

John
=:->

> 
> --
> Martin
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051031/5be3812e/attachment.pgp 


More information about the bazaar mailing list