Bugzilla, Yahoo and SCM interfaces

[Fergus Sullivan]

I missed the following in the thread on Yahoo's use of Bugzilla and  
our integration with other systems.  Sorry for the delayed response,  
Kristis.

On Wed 29-Aug-07, at 1p44 , Kristis Makris wrote:

> Could you elaborate on how Bugzilla "interfaces" with the SCM
> repositories ? Do your repositories also interface with Bugzilla ? How
> do you handle change management in such a big organization ? Could
> Scmbug be of help ?
>
> http://freshmeat.net/projects/scmbug/

Until last year, Yahoo used its own custom email gateway to allow  
mails to be sent to our Bugzilla instance.  (We now use the vanilla  
Bugzilla.org gateway, with a few small tweaks.)

An early expansion of this was a set of CVS hooks whereby anything  
checked into our CVS with a commit message of "[bug 1234] Foo" would  
add the comment "Foo" to bug 1234.  This soon expanded to allow "[fix  
bug 1234] I am fixing this bug" would also mark the bug as resolved  
fixed.  These instructions would be sent from our CVS repository to  
Bugzilla via our email gateway.  In each case we'd include a link to  
a viewcvs page showing the diffs of all files impacted.

Fast forward a few years, through a few corporate acquisitions, and  
we realize the following:
   - Email is not a good machine-to-machine messaging system.
   - We need much better auditing and controls of check-ins.
   - Parts of the company use CVS, but some use Perforce, and some  
use Subversion.  Some use a different CVS repository.  Some use a  
different instance of Bugzilla.
   - We have a legal requirement to follow the life-cycle of revenue- 
impacting code.
   - We need process, Dagnabit!

Accordingly, a large division of yahoo (although not the entire  
company) implements the following rules.
1) You can only check in code if you reference a bug when doing so.
2) You can only check in code for a bug that is assigned to you.
3) You can only check in code on a branch that corresponds to the  
target milestone of the bug.  We maintain a mapping of these  
relationships.

Obviously, this cannot be achieved using the old email interface, so  
instead we built web services connecting source code with bugzilla.

So our current Bugzilla interface with SCM is a mixture of of email  
and web services.  Some projects have permissive check-in policies,  
some restrictive.  And we have three different SCM technologies.  We  
have merged our multiple Bugzilla instances.

In the future, we plan to integrate Bugzilla and SCM more tightly  
with automated builds and automated testing.  The nirvana, of course,  
is to have failed regression tests automatically open or reopen the  
appropriate bug, and newly passing tests to annotate that fact in  
bugzilla.

Thus any solution we use needs to be sufficiently modular to allow  
for acquisitions and changes in coding practice.

I can't properly comment on Scmbag without exploring it more fully.   
It certainly looks as though it shares many of the same goals as our  
own initial implementation.  I very much like the idea of a  
many::many relationship between scm and bug tracking system.  Yahoo's  
implementation will need to be properly rationalized at some point in  
the next year so we'll certainly come back and look more closely at  
Scmbag then.

   /ferg

-- 
fergus sullivan | developer tools team | fergus at yahoo-inc.com | o.  
408.349.6807 | m. 408.203.FERG