On Scmbug

Fri Jun 4 21:11:50 UTC 2004

> Once again apologies for being so grumpy. I'm not normally _that_ bad.

I just spend 1:30 hours replying to this email and accidentally deleted
it. Evolution my **#$% you piece of #$%)(**%^#@... ehem. I know you feel! This time my response is
a lot shorter.

> idea. Welcome aboard :)

:)

Mark and John, feel free to jump in here.

> > 
> > > 2) To be honest, I've pretty much gone off the idea of having the scm
> > > system fiddling directly with the bz DB. The main problem is that as bz
> > 

> It also solves one of the other big problems - mapping cvs usernames to
> bz logins. Your solution is workable, but I think the correct way of
> doing that sort of thing is by adding an extra field to the user table.

I do think its the right think to do. Where do you draw the line ? Will
you add a one-to-many relation of files affected per bug and their
version numbers ? What happens if gnats does not offers an extra field ?
scmbugd can support either methods, or even do so according to the
bugzilla version (what I have works for 2.14, but could be changed to
behave differently for 2.20 if you add such a feature). What happens when some of us move a directory by hacking directly a CVS repository, and then decide they want that change reflected in bz. This a hack around a hack scenario, but I'm just throwing some ideas out there.

> Do you have a list of other bug trackers that you'd like to see
> supported? The only one I can think of that is worth pondering is gnats,
> but lets not give gnats users any more reason to stay with it ;)

Between you and me I agree, but I still want to keep this a generic
"change management" activity with "logging" integration. This could be
svn->bz, cvs->clearquest, rcs->blog or webpage, router config change ->
bz, etc. Mark likes RCSing all configuration files in /etc, and I'm sure wouldn't oppose to some RCS to bz integration.

> The other question is how many setups are actually going to have
> multiple SCMs talking to one bug tracker (or even more unlikely - the

I don't know, but why limit people's options when we don't have to ? (I
can swear I had a stronger argument for this). I'd like to add support
for once scmbugd supporting multiple glue->bugtracking connections, so
that one daemon can integrate cvs->bz for some products, and svn->gnats
for others (if that's what your new high-paying client uses!).
(http://bugzilla.mkgnu.net/show_bug.cgi?id=279)

> other way round)? And once you've solved the problem of a) getting the
> data from the scm, and b) getting it into the tracker anything in the
> middle that doesn't need to be there is simply potential maintainance
> and support problems. 

Not quite simply. I've experienced such maintainance and support
problems in the past by not having this middle man:
1 - setting the minimum characters of a log message is done once in the
daemon, rather than in 17 glued repositories. Same for changing various
checking policies, such as the status of the bug before you commit (may
want to allow commits against "closed"  or "confirmed" bugs). Same for
changing the format of your commit messages, and adding other daemon
features (emulate atomic cvs commits, moin-moin autolinking, etc.)
2 - What happens when you setup your own cvs repository on your laptop
for testing, but your laptop username does not match the one used in
your LAN for bz ? Having this extra authentication layer would permit
Joe Schmoe to authenticate against his custom text file, or through
other mechanisms, or not at all (in testing  maybe ??)! 
3 - Extracting changelog information should happen through scmbugd
(http://bugzilla.mkgnu.net/show_bug.cgi?id=80 - I'm still thinking about
this). Windows users would not be prohibited from getting such logs,
only because they are missing a bunch of Perl libraries, and neither
should Linux users need some graph drawing libs in their local
workstations to create a changelog and make a product release. Scmbugd
should take solve this problem in a central location.
4 - The glue code should generally be immutable, and have the backend
daemon upgraded for newer functionality (I need to fix
http://bugzilla.mkgnu.net/show_bug.cgi?id=213). Eg fixing a single
'quotes' bug on the daemon is better than fixing it in 17 repositories!
5 - You can hide your mysql database behing port filtering on the same
machine scmbugd runs, rather than directly hit it from any repository
location.
6 - I tried setting up the bz email gateway when I desperately needed
it. My ISP was blocking port 25. With scmbugd I can configure the glue
to connect to any port I want, and run scmbugd at any port I want.
7 - You get integration logs in /var/log/scmbug rather than look in sendmail or whathaveyou logs to see if your integration went through, and if not what the problem was.

> In the case of cvs->bz or svn->bz it gives you nothing. I also feel

It gives you a common source of upgrades (and everything mentioned
above). scmbugd is also a common source for blocking development, but
then so is bugzilla. At least you know that you are down, which is better than
sending email without any notification of whether the bz commit
succeeded. Notification from Scmbug is synchcronous. Worst case scenario, you can disable the glue. But at least
you are conscious that you did that! It also permits scmbugd to solve some
problems bz shouldn't have to deal with (and neither should gnats, or anybody else), such as cvs's lack of atomic
commits.

> quite wary of having a long-running deamon process written in a
> scripting language (been there, done that).

I haven't. What should I be careful of?

> You might want to use http://bugzilla.mozilla.org/show_bug.cgi?id=199116
> instead, which is the canonical location for all work on the cvs->bz
> patches that I do.

Hey thanks!

> That was a hacky solution that was the only thing we could think of at
> the time. Again, it simply adds to the complexity of getting the system
> set up, and that is something I quite desperatly want to get away from.
> Having people patch and recompile CVS is Wrong. It also breaks if there
> are quotes in filenames.

Why isn't this fixed in the CVS codebase yet?

> To add to my points above about supporting multiple SCMs/bug trackers,
> I'd rather have a solution that supports a very limited (but common)
> selection setups, but which is as easy as is possibly to set up and
> maintain.

There's an installation script for the glue, and the glue includes an
"enabled" flag if you want to disable it. The scmbugd requires 1 configuration file,
and the bugzilla source. You start it, it runs. 

Lets face it. You shouldn't have to provide a custom solution to a
generic problem. You should use a generic solution, and customize it to
your own environment. You shouldn't be providing such integration in bz.
It's very much needed, but that's not where it belongs.

> > > 7) You might want to think about nicking our bz->viewcvs autolinking

***Never***. I'd rather "reuse" one of your functions. I consider
globals.pl your official interface, until you tell me otherwise!

> To get that working we added one new function to globals.pl, added some
> code to another function, and added some code to the parameters page.
> The patch should be straightforward enough.

Is this in 2.16 ? 2.18 ? What's the name of the function ?

> I should also perhaps mention that my reason for doing this work in
> the first place was so that we could use bz at work

I needed this integration desperately, but frankly cvszilla, McIntere's
work, and the email gateway just didn't work for me. Plus I could not reuse
any of their source at all. Everybody assumed a certain schema, certain bz
version, provided certain features I did not want and could not disable (cvszilla modified the
bz schema!) or had some dirty code tangled up in blue. Lets solve this
problem once and for all. Standardize on an integration protocol and
interface. I was aiming for a svn -> bz integration (which is part of Mark's bigger plan for a change request tool), but wanted to get
cvs working first, since that's what I was mostly familiar with and used
John's integration before. Practically I just changed the design. The ideas for most of the goodies are his.

> So my interest in handing the sort of serious vote-winning ammo that scm
> integration gives to inferior tracking systems is very limited. The next
> time I end up having to fight that battle I'd like to have a trump card
> up my sleeve, thankyou very much ;)

Thanks. I'd better get to work then!