Scmbug

[Dave Swegen]

On Tue, Jun 01, 2004 at 11:41:30AM -0300, Christian Robottom Reis wrote:
> On Tue, Jun 01, 2004 at 11:47:26AM +0100, Dave Swegen wrote:
> > is much better" just isn't going to work. I very nearly didn't bother
> > looking any further at that point...
> 
> C'mon, Dave. It's a first announcement. :-)

You're right. I apologise for the grumpy tone. It must be the joy at
being back at work after a three day weekend that got the better of me :)

> 
> > 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
> > starts working with more DB backends, and schemas change, the script is
> > going to have to keep up. More maintainance overhead, and you also miss
> > out on nice things like sanity checking the SQL. FWIW, the next version
> > of the cvs->bz integration will probably talk via the bz web ui (which
> > is going to need some work).
> 
> I'm probably available to do the backend work to help you here. Do you
> have an idea of what sort of interface you need? It's nothing more than
> adding a comment to a bug, which requires credentials but not much more.
> 
> Note that Justdave has [secretly?] written a bugzilla-change script (in
> the line of bugzilla-submit) that already changes a bug report from the
> commandline, so I guess you could at least harness some of the posting
> code from there. Probably not too hard, I think.

I had a look at it a while back, and the main bit that needs doing is
cleaning up the interface (the --dont_change-- stuff is somewhat grotty,
and I seem to recall that adding comments wasn't working). I haven't
really had time to get the hang of what is going on in process_bug.cgi.

Also, if an error is encountered while submitting changes to multiple
bugs the process stops as soon as the error is encountered, rather than
printing an error and continuing. For the purposes of the cvs->bz
script, this would be bad (mainly for performance reasons).

I got partway through hacking things to work - I need some more time to
get it working properly. 

The horrible truth is that we can hack all sorts of stuff into bz, but
what it really needs is a nice, consistent and defined interface that
can deal with non-interactive external programs.

> 
> > 5) A common request we have is that when a single commit that covers
> > files in multiple directories is made, only one message will be placed in
> > bz. I couldn't see anything in your code that dealt with this, but if it
> > isn't there you might want to keep that in mind. I still havn't come up
> > with a nice clean solution to this.
> 
> This isn't a very easy thing to do. My immediate suggestion is grouping
> checkins by time and userid and somehow storing it temporarily
> "somewhere" (file storage somewhere?), and then periodically sweeping
> through that file and adding comments that are, let's say, five minutes
> old, to the bug. That requires something daemon-like and isn't a very
> clean solution, but then again, lack of atomic commits in CVS is a dirty
> problem.

This is a hard problem to do right. Somebody mailed the CVS list with a
system that apparently almost worked, but I couldn't be asked to look at
some 'normal' perl code at the time ;) But that feature is something
that could wait.

The upside of doing it is that the CVS commit would be instantaneous,
rather than having to wait for the script to finish talking to bz (which
as we all know can take a while). It would also cope better with bz
being down or otherwise unavailable. 

The downside is that the user wouldn't get to see error messages, and
that it might take a while before comments appear in the relevant bugs.

> 
> > 7) You might want to think about nicking our bz->viewcvs autolinking
> > stuff, and modifying it to cope with the format of your commit messages.
> > For a lot of the users of our stuff this a major nice feature.
> 
> What about some bz->bonsai autolinking while we're at that? :-)

Shouldn't be too hard. Surely it should just be a case of coming up with
what links you want for files and versions and changing the URLs we use
to something else. Then again, I know very little about bonsai, apart
from that it makes bz look pretty by comparison.

> 
> > The only thing that I believe your system improves on over ours is the
> > delivery method, which looks much, much easier to set up and configure.
> 
> Delivery method?

The delivery method from cvs to the script that bungs things into bz: We
use email, and this new method uses a custom server. Otherwise the
functionailty is pretty much the same. It has one or two features that
we don't do, such as optionally adding a new version to a product based
on the tag of the comment.

I've actually got a semi-written RFC on how to proceed, but I haven't
got round to finishing it or posting it. Maybe one day...

My unrealistic aim is that one should be able to make an intial commit
of the entire linux 2.6 source tree without too much pain ;)

Cheers
    Dave