some pqm and bzr setup questions?

Mon Mar 9 19:22:21 GMT 2009

Hello, Bazaar team,

I have some questions about setting up bzr with pqm.

Question 1:  Is this bzr/pqm layout correct for an automated gatekeeper
workflow against a subversion repository?

Here's the diagram of the layout:

svn --> master --> dev1:mirror --> dev1:work --> public:work --> pqm -->
target --> svn (back to same svn repo)

               |-------> dev2:mirror --> dev2:work --> public:work2
----|

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.

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:

:0:

| `/users/autotest/bzr-projects/pqm/bin/pqm -v -d --report --read`

This procmail recipe ends up creating a new patch.XXXX file in the
~/pqm-queue directory.

Now I manually run the following (I haven't put this on a cron job yet,
running it manually now for testing):

pqm -v -d --report --run

(Question 2: Why am I getting this error?)

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):

'Sender not authorized to commit to branch
file:///users/autotest/bzr-testrepo/automation'

I have the various submit and public branches set in my
.bazaar/locations.conf file (located under pfanelli's home directory):

/users/pfanelli/.bazaar/locations.conf

------------------------------------------------------------------------
-----------------------------------------------

[/users/pfanelli/bzr-repos/tr-automation]

pqm_email = PQM <autotest at localhost>

pqm_user_email = Paul Fanelli <pfanelli at crossbeamsys.com>

submit_branch = file:///users/autotest/bzr-testrepo/automation

public_branch = file:///users/autotest/bzr-public

public_branch:policy = appendpath

------------------------------------------------------------------------
-----------------------------------------------

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):

/users/autotest/.pqm.conf

------------------------------------------------------------------------
-----------------------------------------------

[DEFAULT]

# where should the pqm queue structure, logs etc be placed.

queuedir=/users/autotest/pqm-queue

# what directory to work in - revisions are checked out here, and so
forth.

# defaults to a subdir of queuedir. Normally not set.

#workdir=

# where are logs stored - similar to workdir.

#logdir=

#master logfile location. Again, default should be all you need.

#logfile=

# what keyring to verify emails from. Trusts all user in the keyring.

# Place ONLY users you trust to commit in this keyring.

keyring=/users/autotest/.gnupg/pubring.gpg

# where is the tla/baz/arx program - usually not needed

#arch_path=/path/to/tla

# what is the pqm name. Normally not set.

#myname=Patch Queue Manager

# what email address should pqm send out it's address's from.

from_address=autotest at cuda

# send notification on success and failure. normally not set.

mail_reply=0

# verify gpg signatures on email. DISABLING ALLOWS ANYONE TO TRIGGER
MERGES.

# BEWARE!!!!!!!!!!

verify_sigs=1

# don't override the home dir. Use and set to 1 if you:

# have setup a uid just for pqm

# have the queuedir != to the pqm homedir.

# if you followed the manuals example of /usr/src/tla-pqm for the pqm
homedir,

# and you use anything other than /usr/src/tla-pqm for the queuedir, you
would need this.

dont_set_home=1

# an external command to allow/disallow commits.

# Return non-zero to signal error.

#precommit_hook=foo-bar.sh param1 param2

precommit_hook=/users/autotest/precommit_hook.sh

# Build a config-manager config before doing any merges etc.

# Allows precommit hooks to work with config-based packages.

#build_config=foo at bar/c[[--b]--v]/configs/foobar/development

# Define a default project for all branches.

# Branches with projects appear in the web status ui under the

# /projects/project-name path rather than at the / status page.

# This allows multiple projects to share a single PQM but not

# have their merges lost in the noise of branches going through.

#project=demonstration-system

#define groups

#groups=staff

#[staff]

members=pfanelli at crossbeamsys.com

[location overrides]

# this sections provides location mappings - where a

# configuration (and eventually normal sections)

# reference something, a local reference which may

# (for instance) be read-write, or faster, is used.

# /new/value=http://public-value.com

# This section enables merges into this branch.

[/users/autotest/bzr-testrepo/automation]

# per section keys follow

#published_at=http://hello-world.example.com

published_at=http://localhost/~/bzr-testrepo/automation

#publish_to=hello-world.example.com:public_html

# an external command to allow/disallow commits.

# Return non-zero to signal error.

#precommit_hook=foo-bar.sh param1 param2

# Build a tla config before doing any merges etc.

# Allows precommit hooks to work with config-based packages.

#build_config=foo at bar/c[[--b]--v]/configs/foobar/development

# Use a specific base directory instead of a dynamically calculated one.

#build_dir=/home/temp/foo

# restrict commits

#commiters=staff

commiters=pfanelli at crossbeamsys.com

# Confirm that commit messages match a specified regexp.

# Allows a policy to be defined (per-revision) for what the commit

# messages must look like (providing they can be described by a regular

# expression)

# The regexp is automatically anchored at the start of the message

# so if you need it to match later, put .* at the start of your

# regexp

#

# This example matches rs=bar, r=foo and [trivial] caselessly

#commit_re=.*([rR][sS]?=[^ \t]+)|(\[[Tt][Rr][Ii][Vv][Ii][Aa][Ll]\])

commit_re=.*

# Assign a specific project to this branch

#project=hello-world

# arch-tag: Simple sample configuration file for tla-pqm

------------------------------------------------------------------------
-----------------------------------------------

I would really appreciate any insight into this bzr/pqm workflow
process.

Best regards,

Paul Fanelli

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20090309/4dea1c83/attachment-0001.htm 