On Scmbug

[Mark Reibert]

On Mon, 2004-06-14 at 11:22, Kristis Makris wrote:
> You may only be interested in having commit messages sent in bz, but
> from an scm-integration perspective I'm also interested in those being
> refused when a bug is closed, or assigned to someone else, or when the
> log size is less than 50 chars, and I need the cvs commit to fail if
> that's the case (so the email interface would not work for me). Again,
> that's why I wrote this. Do you think all those additional features
> should be developed in bugzilla, a bug tracking system, or as part of an
> scm-integration package ? 

Part of the integration glue - see below.

> How about allowing for integration developers to provide all the
> features requested by everyone, with the option of selectively choosing
> which features each user might want active ? As you mentioned, the only
> problem is that you don't know what's needed, and you shouldn't! Some
> scm-integration people should come to you saying "we want to add feature
> X, Y, and Z and we need this kind of support from bz". You should only
> implement the support, not the feature. For example, bz should provide a
> function called AppendToComment() that lets someone append commit
> messages to comments. But it shouldn't implement parsing of cvs commit
> messages. Another example (as we discovered) is that you should offer a
> mechanism for mapping cvs/svn usernames to bz email addresses. You
> should implement the SCVCUsername_To_BugzillaUsername() function, but
> nothing more. The point is that any work done towards improving
> bugzilla-watcher is a waste of time, since someone else will eventually
> need more features than the email gateway (or even a custom libraries
> approach) can provide. ALL those additional features should be developed
> somewhere else. Those features could be distributed in a
> custom-libraries fashion, a client/daemon scheme, or in any other way
> one might want to distribute them, but they should NOT be part of the
> bugzilla source tree.

below:

The solution is to have the integration glue take care of the
integration logic. (Earth shattering, I know! ;-) The revision-control
and the change-management tools simply provide hooks and APIs that allow
the glue to do its thing. On the revision-control side of things this
means triggers. (Well, the trigger itself is part of the integration
glue ... the *ability* to trigger is what we get from the tool.) With
respect to the change-management tool, we need an API that allows us to
both query and update the system. This should take the form of a web
service, WebDAV, socket, or something that allows the glue to work both
from local and remote installations. (bz's globals.pl is not sufficient
because it cannot be accessed remotely.) Whatever we put between the
trigger and the change-management API (Kristis' daemon, a library call,
etc.) is glue implementation detail.

So, what does this mean for our hypothetical bz API? Well, we definitely
need functions like AddComment(), GetBugOwner(), GetBugState(), etc.,
but we do not want something like SCVCUsername_To_BugzillaUsername().
This is integration glue stuff - if the glue needs to translate user
names then it is the responsibility of the glue to manage the mapping.

All we have to do now is define the bz API!

Mark

-- 

----------------------
Mark S. Reibert, Ph.D.
mark at reibert.com
----------------------