pqm for bzr development

[Erik Bågfors]

How about adding this kind of functionality into bzr itself?  Look at
how darcs handles it. It's one if the nicest things about darcs.

a darcs "server" can simply be a mail address you mail to, that runs
all mails trough pgp and then applies them if they match (you can add
tests as well by just adding "apply test" to the repo config file).

for example a procmail can look like this

:0:
* ^TOmy darcs repo
|(umask 022; darcs apply --reply user at host.com \
    --repodir /path/to/your/repo --verify /path/to/the/allowed_keys)

That's a dead simple way to set up a "server" for trusted people to submit to.

I don't know how pqm works and it might be lot's better, but having
this functionality built into bzr has lot's of advantages I think.

Regards,
Erik

2005/10/31, Martin Pool <martinpool at gmail.com>:
> 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.)
>
> 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.
>
> 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.
>
> 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?
>
> --
> Martin
>
>