Bugzilla, Yahoo and SCM interfaces
fergus at yahoo-inc.com
Wed Sep 5 19:49:28 UTC 2007
I missed the following in the thread on Yahoo's use of Bugzilla and
our integration with other systems. Sorry for the delayed response,
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 ?
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-
- 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
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
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
fergus sullivan | developer tools team | fergus at yahoo-inc.com | o.
408.349.6807 | m. 408.203.FERG
More information about the developers