On Scmbug

[Dave Swegen]

On Fri, Jun 04, 2004 at 02:11:50PM -0700, Kristis Makris wrote:
> > > > 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

The problem with that approach is that it becomes unmanageable for large
installations. If, hypothetically, mozilla.org was to start using cvs
integration it would mean that every time a dev with commit rights
changes their email address/login, some admin would have to change their
cvs->bz mapping too. That means that either you have to hack bz to
notify the admin, or the user has to notify the admin. Both solutions
are somewhat suboptimal.

> > 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.

Yikes! This is way beyond anything that I was thinking of. I'll say
this: You've certainly got ambition :)

> 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!

That is a good point. It certainly scales better. But then how often do
you have 17 cvs repositories that aren't on the same machine? If nothing
else I might nick your approach of having stuff in libraries.

> 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.

As I said, I believe talking directly to the DB is wrong (at least in
the case of bz).

> 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.

I quite agree: The mail interface is wrong.

[stuff snipped]

> 
> > 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?

Oh, at the time (I think this was with perl 5.0-something), perl had
really iffy signal-handling (and this was code that forked a lot). It
meant that the daemon would crash randomly from anything between 2
minutes and 20 hours. I eventually figured it out, but only after
hurling abuse at my monitor for a week.

It sort of left me feeling nervous about these things :)

> > 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?

I don't know if Steve has gotten it in yet (I'm pretty certain it goes
in Debian's CVS packages). From what Steve has been telling me the CVS
maintainers have changed the way the commitinfo stuff works, but I
haven't looked at it. Apperently it is a far more sane way of doing
these things.

> 
> > 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!

Aah. Maybe I should clarify things: When I say 'our' I don't mean
bugzilla's, I mean 'the two employees of Plasmon Data Ltd who have
hacked together some cvs-> integration stuff' :) Bugzilla has yet to
accept any cvs integration stuff, and that includes the autolinking
code. The code in question is in patch #3, and is subject to change.

> 
> > 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've made versions of patch #3 for both 2.17.1 and 2.16.5, and plan on
updating the patches to 2.18 soonish.

Basically, my aims are as follow (I think):

* Something that is simple to set up, and simple to maintain (both for me
and the admin)
* Something that works on the systems I'll most likely will be working on
(bz, svn, cvs)
* Something that simply puts formatted commit comments into bz. I have
little interest in something that changes the bz db in any further ways
via commit comments: There are too many ways that the bz db can get into
an iffy state that way (we regularly have people committing against the
wrong bug - I dread to think what it would be like if other changes
could take place due to incorrect commitlog data).
* Something that will go into bz proper, as I don't have the time to
maintain a pile of external patches.

But my primary problem on what should be done is that I have very little
idea of what other people want in such a system. You said that our
patches weren't enough, but Steve has had some feedback stating that the
patches were spot-on. I just don't know... 

Anyway, it's taken me ages to reply to this, and I'm just wibbling now,
so I'll stop :)

Cheers
    Dave