<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=Content-Type content="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 11 (filtered medium)"> <style>  </style> </head> <body lang=EN-US link=blue vlink=purple> <div class=Section1> Hello, Bazaar team,<o:p></o:p> <o:p> </o:p> I have some questions about setting up bzr with pqm.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Question 1:  Is this bzr/pqm layout correct for an automated gatekeeper workflow against a subversion repository?<o:p></o:p> <o:p> </o:p> Here’s the diagram of the layout:<o:p></o:p> <o:p> </o:p> svn à master à dev1:mirror à dev1:work à public:work à pqm à target à svn (back to same svn repo)<o:p></o:p>                |-------> dev2:mirror à dev2:work à public:work2 ----|<o:p></o:p> <o:p> </o:p> I am using the bzr-svn plugin to mirror the svn repository into ‘master’.  Each developer will create a mirror branch off of the master called ‘mirror’.  Then when a developer wants to fix a bug or start a new feature, they branch off of ‘mirror’. This is what I call ‘work’ in the diagram above.  Another best-practice I suggest is pushing the work unit to a public place and then binding their private work unit to it, so that when they commit their work, the public work unit gets automatically commited (the private and public work units stay in sync and provide a backup of their work).  Also the pubic work area provides a way for developers to collaborate on a bug-fix or new feature and provides a place for code reviews.<o:p></o:p> <o:p> </o:p> When the bug-fix or feature is complete, the developer submits the work unit to pqm (I am using the bzr-pqm plugin).  Pqm is running under a user called autotest. We have our svn repository authenticating against NIS and autotest is in NIS and svn is setup to allow autotest to commit/write access (I wanted to create a new user called ‘pqm’ but I don’t have permissions to add a new user and get it added to NIS and modify the svn permissions to allow pqm write access, etc).  When I issue, ‘bzr pqm-submit –m “pqm submit test”, the gpg-signed email gets delivered to the autotest user. I have a .forward file that kicks off procmail and I have a procmail recipe that processes the email as stdin as such:<o:p></o:p> <o:p> </o:p> :0:<o:p></o:p> | `/users/autotest/bzr-projects/pqm/bin/pqm -v -d --report --read`<o:p></o:p> <o:p> </o:p> This procmail recipe ends up creating a new patch.XXXX file in the ~/pqm-queue directory.<o:p></o:p> Now I manually run the following (I haven’t put this on a cron job yet, running it manually now for testing):<o:p></o:p> <o:p> </o:p> pqm -v -d --report --run<o:p></o:p> <o:p> </o:p> (Question 2: Why am I getting this error?)<o:p></o:p> When I run the above pqm command issue, I am getting this error message from pqm (in a patch.XXX file in pcm-queue/logs):<o:p></o:p> <o:p> </o:p> ‘Sender not authorized to commit to branch <a href="/users/autotest/bzr-testrepo/automation">file:///users/autotest/bzr-testrepo/automation</a>’<o:p></o:p> <o:p> </o:p> I have the various submit and public branches set in my .bazaar/locations.conf file (located under pfanelli’s home directory):<o:p></o:p> <o:p> </o:p> /users/pfanelli/.bazaar/locations.conf<o:p></o:p> -----------------------------------------------------------------------------------------------------------------------<o:p></o:p> [/users/pfanelli/bzr-repos/tr-automation]<o:p></o:p> pqm_email = PQM <autotest@localhost><o:p></o:p> pqm_user_email = Paul Fanelli <pfanelli@crossbeamsys.com><o:p></o:p> submit_branch = file:///users/autotest/bzr-testrepo/automation<o:p></o:p> public_branch = file:///users/autotest/bzr-public<o:p></o:p> public_branch:policy = appendpath<o:p></o:p> -----------------------------------------------------------------------------------------------------------------------<o:p></o:p> <o:p> </o:p> <o:p> </o:p> So I think I have something mis-configured in my .pqm.conf file.  Here is my .pqm.conf file (located under the autotest’s home directory):<o:p></o:p> <o:p> </o:p> /users/autotest/.pqm.conf<o:p></o:p> -----------------------------------------------------------------------------------------------------------------------<o:p></o:p> [DEFAULT]<o:p></o:p> # where should the pqm queue structure, logs etc be placed.<o:p></o:p> queuedir=/users/autotest/pqm-queue<o:p></o:p> <o:p> </o:p> # what directory to work in - revisions are checked out here, and so forth.<o:p></o:p> # defaults to a subdir of queuedir. Normally not set.<o:p></o:p> #workdir=<o:p></o:p> <o:p> </o:p> # where are logs stored - similar to workdir.<o:p></o:p> #logdir=<o:p></o:p> <o:p> </o:p> #master logfile location. Again, default should be all you need.<o:p></o:p> #logfile=<o:p></o:p> <o:p> </o:p> # what keyring to verify emails from. Trusts all user in the keyring.<o:p></o:p> # Place ONLY users you trust to commit in this keyring.<o:p></o:p> keyring=/users/autotest/.gnupg/pubring.gpg<o:p></o:p> <o:p> </o:p> # where is the tla/baz/arx program - usually not needed<o:p></o:p> #arch_path=/path/to/tla<o:p></o:p> <o:p> </o:p> # what is the pqm name. Normally not set.<o:p></o:p> #myname=Patch Queue Manager<o:p></o:p> <o:p> </o:p> # what email address should pqm send out it's address's from.<o:p></o:p> from_address=autotest@cuda<o:p></o:p> <o:p> </o:p> # send notification on success and failure. normally not set.<o:p></o:p> mail_reply=0<o:p></o:p> <o:p> </o:p> # verify gpg signatures on email. DISABLING ALLOWS ANYONE TO TRIGGER MERGES.<o:p></o:p> # BEWARE!!!!!!!!!!<o:p></o:p> verify_sigs=1<o:p></o:p> <o:p> </o:p> # don't override the home dir. Use and set to 1 if you:<o:p></o:p> # have setup a uid just for pqm<o:p></o:p> # have the queuedir != to the pqm homedir.<o:p></o:p> # if you followed the manuals example of /usr/src/tla-pqm for the pqm homedir,<o:p></o:p> # and you use anything other than /usr/src/tla-pqm for the queuedir, you would need this.<o:p></o:p> dont_set_home=1<o:p></o:p> <o:p> </o:p> # an external command to allow/disallow commits.<o:p></o:p> # Return non-zero to signal error.<o:p></o:p> #precommit_hook=foo-bar.sh param1 param2<o:p></o:p> precommit_hook=/users/autotest/precommit_hook.sh<o:p></o:p> <o:p> </o:p> # Build a config-manager config before doing any merges etc.<o:p></o:p> # Allows precommit hooks to work with config-based packages.<o:p></o:p> #build_config=foo@bar/c[[--b]--v]/configs/foobar/development<o:p></o:p> <o:p> </o:p> # Define a default project for all branches.<o:p></o:p> # Branches with projects appear in the web status ui under the<o:p></o:p> # /projects/project-name path rather than at the / status page.<o:p></o:p> # This allows multiple projects to share a single PQM but not<o:p></o:p> # have their merges lost in the noise of branches going through.<o:p></o:p> #project=demonstration-system<o:p></o:p> <o:p> </o:p> #define groups<o:p></o:p> #groups=staff<o:p></o:p> #[staff]<o:p></o:p> members=pfanelli@crossbeamsys.com<o:p></o:p> <o:p> </o:p> [location overrides]<o:p></o:p> # this sections provides location mappings - where a<o:p></o:p> # configuration (and eventually normal sections)<o:p></o:p> # reference something, a local reference which may<o:p></o:p> # (for instance) be read-write, or faster, is used.<o:p></o:p> # /new/value=http://public-value.com<o:p></o:p> <o:p> </o:p> <o:p> </o:p> # This section enables merges into this branch.<o:p></o:p> [/users/autotest/bzr-testrepo/automation]<o:p></o:p> # per section keys follow<o:p></o:p> <o:p> </o:p> #published_at=http://hello-world.example.com<o:p></o:p> published_at=http://localhost/~/bzr-testrepo/automation<o:p></o:p> #publish_to=hello-world.example.com:public_html<o:p></o:p> <o:p> </o:p> # an external command to allow/disallow commits.<o:p></o:p> # Return non-zero to signal error.<o:p></o:p> #precommit_hook=foo-bar.sh param1 param2<o:p></o:p> <o:p> </o:p> # Build a tla config before doing any merges etc.<o:p></o:p> # Allows precommit hooks to work with config-based packages.<o:p></o:p> #build_config=foo@bar/c[[--b]--v]/configs/foobar/development<o:p></o:p> <o:p> </o:p> # Use a specific base directory instead of a dynamically calculated one.<o:p></o:p> #build_dir=/home/temp/foo<o:p></o:p> <o:p> </o:p> # restrict commits<o:p></o:p> #commiters=staff<o:p></o:p> commiters=pfanelli@crossbeamsys.com<o:p></o:p> <o:p> </o:p> # Confirm that commit messages match a specified regexp.<o:p></o:p> # Allows a policy to be defined (per-revision) for what the commit<o:p></o:p> # messages must look like (providing they can be described by a regular<o:p></o:p> # expression)<o:p></o:p> # The regexp is automatically anchored at the start of the message<o:p></o:p> # so if you need it to match later, put .* at the start of your<o:p></o:p> # regexp<o:p></o:p> #<o:p></o:p> # This example matches rs=bar, r=foo and [trivial] caselessly<o:p></o:p> #commit_re=.*([rR][sS]?=[^ \t]+)|(\[[Tt][Rr][Ii][Vv][Ii][Aa][Ll]\])<o:p></o:p> commit_re=.*<o:p></o:p> <o:p> </o:p> # Assign a specific project to this branch<o:p></o:p> #project=hello-world<o:p></o:p> <o:p> </o:p> # arch-tag: Simple sample configuration file for tla-pqm<o:p></o:p> -----------------------------------------------------------------------------------------------------------------------<o:p></o:p> <o:p> </o:p> <o:p> </o:p> I would really appreciate any insight into this bzr/pqm workflow process.<o:p></o:p> <o:p> </o:p> Best regards,<o:p></o:p> <o:p> </o:p> Paul Fanelli<o:p></o:p> <o:p> </o:p> </div> </body> </html>