Scmbug

[Dave Swegen]

On Tue, Jun 01, 2004 at 06:10:51PM -0300, Christian Robottom Reis wrote:
> On Tue, Jun 01, 2004 at 05:13:54PM +0100, Dave Swegen wrote:
> > 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.
> 
> As I said, I think justdave's script might already handle this part.

Ah, sorry, didn't realise you meant that part. I'll try and get round to
looking at it again.

> 
> > 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).
> 
> What sort of error?

As soon as an attempt is made to modify a non-existant bug for instance,
processing will stop. For this sort of thing it would be better if it
spat out the error, but continued. That way the cvs->bz script would
only have to be run once, and not have to be restarted after every
error.

I have got part of the way to modifying process_bug to do this, but got
stuck when trying to figure out how to actually display the errors.

> 
> > 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.
> 
> /me shrugs. I don't find the CGI interface so bad to deal with; of
> course, parsing the returned data is sucky, but parsing XML is sucky
> as well and the upside is that it works now.
> 
> Of course, a real interface would be much better, but we don't have one
> right now (and I'm not volunteering to work on one ATM either).

Same goes here, so I'll try and work with the current interface.

> 
> > 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. 
> 
> Well, you say below you're using an email interface, so the CVS commit
> would have to wait, at the most, for email to be dispatched, right?

I want to get shut of the email interface. It's a pain to set up,
a potential DoS route, and doesn't work on win32 (depends on procmail,
which I understand is nigh-on impossible to emulate on win32).

> 
> > > 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.
> 
> To be honest, the links should probably have the same syntax and just
> point to different servers depending on which system you have installed.
> A simple param could configure if we've got bonsai, viewcvs or cvsweb,
> for instance.

ATM the param is simply a URL. Should be simple enough to change.

Cheers
    Dave