Project Management with Bugzilla, CVS and Mailing lists

Philip S Tellis

Yahoo! Inc

Ubuntulive • July 22-24, 2007 • Portland, Oregon

Do you manage a distributed project?

Is communication between your developers efficient?

What's needed?

Project management requirements

Source control including reviews
Issue tracking linked to code changes
Dependency and progress tracking
Group communication
Generate ChangeLog and Release Notes

Code reviews

When? Before checkin or after checkin?
How? Via email or using an issue tracker?
How do reviewer comments get recorded?
How to track changes in a patch before commit?

Issue tracking

Traditionally one would use email to report issues
Records are not easily locatable
Need responsibilities, targets, severity and priorities for issues
Need fields to report components and versions where issues occur

Tracking bug fixes

Submit patches as attachments to an issue
Newer patches obsolete an older patch
CVS logs should reference a bug in bugzilla
CVS log messages update bug comments and time spent

Communication

Face to face meetings - seriously... does anything happen?
Teleconferences - often chaotic
email, IRC, message boards
Can we use bugzilla?

We'll get back to that in a bit

for now, let's manage code

The `CVSROOT` directory

rcsinfo - template for log messages
verifymsg - script to verify log message
loginfo - script to run after commit
checkoutlist - additional admin files

Let's try something

All commits must be against a bug

Prompt the user for a bug id at commit time
Don't commit if a bug id isn't passed

All commits must be against a bug

Prompt the user for a bug id at commit time
Don't commit if a bug id isn't passed

Create a file `tc.template`

BugId:

Create a file `tc.template`

BugId:

Seriously, that's all there is to it!

Create a file `bugid.verify`


#!/bin/sh
if head -1 < $1 | egrep "^BugId:[ ]*[0-9]+$" \
         > /dev/null; then
   exit 0
else
   echo "No BugId found."
   exit 1
fi

Add references to `verifymsg` and `rcsinfo`

Tell verifymsg how to check commits:

^src     /usr/cvssupport/bugid.verify

Tell rcsinfo what to prompt devs for:

^src     /usr/cvssupport/tc.template

Add references to `verifymsg` and `rcsinfo`

Tell verifymsg how to check commits:

^src     /usr/cvssupport/bugid.verify

Tell rcsinfo what to prompt devs for:

^src     /usr/cvssupport/tc.template

Maybe tell config to reread commit message:

RereadLogAfterVerify=always

You could allow something like `BugId: none`

Add this before the else:


elif head -1 < $1 | egrep "^BugId:[ ]*none$" \
         > /dev/null; then
   # It is okay to allow commits with
   # "BugId: none", but do not put that
   # text into the real log message.
   egrep -v "^BugId:[ ]*none$" > $1.rewrite
   mv $1.rewrite $1
   exit 0

Email all devs when someone commits foocide

Add to loginfo:

DEFAULT  $CVSROOT/CVSROOT/syncmail -u %{sVv} \
     devs@foo.com

Use the syncmail script provided in the CVS Book

WT%F are `%s`, `%V`, `%v` and `%{sVv}`?

%s is the filename
%V is the old revision number
%v is the new revision number

Make way for Bugzilla

CVS talking to bugzilla — needs a script

Callable from bugzilla.procmailrc for some alias, eg: cvsbugz@foo.com
Processes message body for bug numbers, and commands (eg: Fix, Close, etc.)
Use CVS loginfo file to mail log messages to this alias

Example commit messages

Added log messages to get more data
[bug 31337 time:1 left:3]

...

Added defenestration logic
Removed redundant log messages
[fix bug 31337 time:3 left:0]

`bugzilla.procmailrc`

.procmailrc file calls cvsbugz.pl for matching mails


    # Check message body for [bug XXXXXX syntax
    :0 Bc
    * \[(fix +)?bug +[0-9]+
    |$HOME/cvsbugz.pl

cvsbugz.pl parses the email for the [bug XXXXX] syntax
update bugzilla using the Bugzilla::Bug perl module

Now, we'll talk

Communication 2.0 — Blogging on Bugzilla

Announcements and high level communication to dev list
CVS log comments to dev list
Bug comments to dev list (use default QA field)
Tasks and TODO comments on Bugzilla
IRC conversations archived as a bug attachment

Where do we stand now?

CVS updates bugzilla, freeing up the developer
Bugzilla links back to cvs patches
cvsweb has links to bugzilla entries
Everything is mailed to your dev list
Devs review code mailed to the dev list and comment on bugzilla

Release time

Use cvs2cl (search for it)
Generate ChangeLogs from CVS logs
ChangeLogs get links to bugzilla
Encourages developers to write meaningful log messages

Release time

Use cvs2cl (search for it)
Generate ChangeLogs from CVS logs
ChangeLogs get links to bugzilla
Encourages developers to write meaningful log messages
(Yeah, right!)

Pointers or References?

Greetz

Philip S Tellis

philip@bluesmoon.info

http://bluesmoon.info/

Ubuntulive - 2007-07-22