On Scmbug

[Kristis Makris]

> Hmmm, I want to see how you get RCS->bz integration w/o the ability to
> trigger in RCS! (I suppose you could wrap all the client commands, but
> who wants to maintain that?)

One could modify the RCS source to add support for consulting an
RCS.conf that is local to a directory (or maybe from /etc). When such a
file is present, the rcs commands could execute triggers as specified an
that file. I'm coming to you with solutions, not problems!

> As I wrote above, you lose flexibility in this sort of centralization.
> Maybe I want different minimum-length comments and checkin policies for
> each repository ...

I think you need both. You should have that flexibility, by specifying a
minimum-length size in each repository. You should also have the option
to override this collectively for all repositories.

> > 3 - Extracting changelog information should happen through scmbugd

> I need to think about this too, but my gut feeling is this should not be
> the domain of the integration tool. However, I reserve the right to
> change my mind!

I think there's room for a separate "release tool" that creates
Changelog information, verifies all the files you are packaging in a
tar.gz have been tagged, verify all source files include the appropriate
license, verify all bugs worked are in a closed/fixed state (or
according to some other policy) etc. I have a separate script I use to
release scmbug that may be of interest.

> In my perfect world the integration glue uses only the published API of
> the change-request tool (web service, socket connection, etc.). Hacking

How do you handle in your perfect world upgrades in the published API
when the glue has not been upgraded in the repository ?

> CVS's lack of atomic commits will be rendered irrelevant when Subversion
> replaces it as the de-facto standard for open-source projects. I am not
> being religious here, I just can't see the world sticking with CVS when
> there is a better tool available. (Of course, there is quite a bit of
> inertia to overcome ...)

I agree here. But this may not be an option for everyone.

> difficult in, say, Subversion as "tags" are simply tree copies. The
> point here is the intersection between the revision-control and
> change-request tools varies with the products and can drive the design
> of the integration code.

> >From the technical side, why a daemon? As I mentioned above, scmbugd is

Primarily because Bugzilla's current public API is the globals.pl file,
and I'm assuming other tools also lack a publicly accessible API. I'm
calling functions out of globals.pl, rather than sent sql statements
that assume a certain schema. I had to add some new functions I'm
planning on submitting for inclusion to Bugzilla as part of their API. 
I prefer to wrap around other people's APIs with what you call a "glue
to change-request API" today, rather than wait for everyone else to make
theirs truly public (ala WebDAV). Since the assumption that the bugzilla
source is uncompressed on each machine that hosts a CVS repository is a
little far-fetched, I'm requiring that source only on the machine
scmbugd runs. This seems to work in practise. I have various integrated
local repositories on my laptop, and some publicly hosted for joint work
with others. I have one publicly accessible Bugzilla instance, and its
mysql datatabase behind port filtering.

As to why I picked a TCP daemon rather than a different service (e.g.
WebDAV)... there's no WebDAV chapter in my Perl book, and with minimum
research a barebones daemon was coded in less than a couple of hours (I
was coding this over Spring break, needed it desperately and had the
whole thing working over a weekend). I think some separation of a "glue
to change-request API" is valuable, but the daemon could be replaced
with a WebDAV service.

> Some day I will send you a diagram of my high-level architecture ideas.

Hehe. My "today" argument is gaining momentum! Also, John's integration
was never publicly released, but an equivalent solution should be
available, and cvszilla just didn't work.