On Scmbug

[Kristis Makris]

On Thu, 2004-06-10 at 00:56, Dave Swegen wrote: 
> The problem with that approach is that it becomes unmanageable for large
> installations. If, hypothetically, mozilla.org was to start using cvs

> I quite agree: The mail interface is wrong.

Assuming we all agree some level of cvs/svn integration with Bugzilla is
needed, that the email interface is wrong, and that the cvs commits
should not go through under certain conditions (e.g. commiting against
bugs not assigned to you, or closed bugs), what would you recommend ?

> 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

Perhaps if you are running Sourceforge and host a lot more repositories
than that on multiple machines? I don't know. I'm trying to think ahead
for cases we might be missing, and ensure scmbug will accomodate those.
This is why I wrote this in the first place. ALL other solutions did not
work for me. I'm sorry, I tried! They weren't flexible enough. As I also
said before, I do have both local cvs repositories on my laptop, and
remote ones on 2 other machines :) Designing integration glue that will
not work in all cases even though you could with reasonably equal effort
design one that works in all cases, already resulted in 3 integration
glue efforts that did not work for ME :) Why limit our options when we
don't have to ?

> else I might nick your approach of having stuff in libraries.
> 
I'd rather you didn't do that so casually. See below...

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

How should one talk to bugzilla for integration purposes ? See below...

> > > Having people patch and recompile CVS is Wrong. It also breaks if there
> > > are quotes in filenames.

I think the stateful parser I posted earlier should now take care of
commas and whitespaces in directories/files in a lot more cases without
any changes needed in CVS.

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

What is Bz's official position on how it would like to be integrated ?
Should integration tools talk to some public WebDAV service provided by
bz ? Directly to the DB ? Using the globals.pl file ? Is bz sticking
with the email interface ? Will cvs/svn usernames be added in bz ? Is
there a plan on making all this happen ? If there's no such plan, I'll
have to continue working around globals.pl.
 
> * Something that is simple to set up, and simple to maintain (both for me
> and the admin)

Agreed.

> * Something that works on the systems I'll most likely will be working on
> (bz, svn, cvs)

Agreed.

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

I see you point here. See below...

> 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.
> 
I couldn't agree more!

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

In summary, my secondary problem is that integration efforts developed
so far will not work in 100% of all setups. My primary problem is that
they are also designed in a way that does not permit them from being
extended to capture all 100% of those cases, and nobody has addressed
this issue.

below:

You may only be interested in having commit messages sent in bz, but
from an scm-integration perspective I'm also interested in those being
refused when a bug is closed, or assigned to someone else, or when the
log size is less than 50 chars, and I need the cvs commit to fail if
that's the case (so the email interface would not work for me). Again,
that's why I wrote this. Do you think all those additional features
should be developed in bugzilla, a bug tracking system, or as part of an
scm-integration package ? 

How about allowing for integration developers to provide all the
features requested by everyone, with the option of selectively choosing
which features each user might want active ? As you mentioned, the only
problem is that you don't know what's needed, and you shouldn't! Some
scm-integration people should come to you saying "we want to add feature
X, Y, and Z and we need this kind of support from bz". You should only
implement the support, not the feature. For example, bz should provide a
function called AppendToComment() that lets someone append commit
messages to comments. But it shouldn't implement parsing of cvs commit
messages. Another example (as we discovered) is that you should offer a
mechanism for mapping cvs/svn usernames to bz email addresses. You
should implement the SCVCUsername_To_BugzillaUsername() function, but
nothing more. The point is that any work done towards improving
bugzilla-watcher is a waste of time, since someone else will eventually
need more features than the email gateway (or even a custom libraries
approach) can provide. ALL those additional features should be developed
somewhere else. Those features could be distributed in a
custom-libraries fashion, a client/daemon scheme, or in any other way
one might want to distribute them, but they should NOT be part of the
bugzilla source tree.

If you can build a reusable module providing the bugzilla support for
integration, I could make it part of a local-libraries-only approach (or
any other approach) that provides cvs/svn/anything else to bz
integration. I already have a list of functions I need provided by
Bugzilla. The major problem I have not addressed yet, is talking to
bugzilla securely. Scmbugd will gladly accept any cvs username you tell
it you are sending data from, and then contact the mysql db using
globals.pl. If your DB and scmbugd are on the same machine, you don't
have to send the mysql db username/password in cleartext over the web.
If not, then this is still a problem regardless of whether you are using
a daemon, or a local-libraries approach. I don't know how that should be
handled. Perhaps talk to mysql securely (I haven't looked in their auth
mechanisms yet -- having mysql exposed to everyone daes not sound like a
good idea) ? Then, Bz must accept that the mysql db port will be
publicly open, update their documentation to describe installation of
mysql in that way, and talk to mysql over some secure authentication
mechanism (that the integration glue can talk to as well). If WebDAV or
any other public interface will be used, be that as it may, but still
provide the designated way one should talk to bz.

I can't do much in terms of redesigning scmbug unless bz answers some of
these questions, and decides if it wants to support being integrated in
a more extensive manner bugzilla-watcher allows. I'll gladly convert to
some universally agreed design that will make everyone happy. But, at
the moment what I have works with adequate security while all other
integration efforts didn't.