On Scmbug

[Jeroen Ruigrok/asmodai]

-On [20040608 20:22], Kristis Makris (mkgnu at gmx.net) wrote:
>One could modify the RCS source to add support for consulting an
>RCS.conf that is local to a directory (or maybe from /etc). When such a
>file is present, the rcs commands could execute triggers as specified an
>that file. I'm coming to you with solutions, not problems!

Don't forget that not every system out there has the sources for the
utilities they ship with the OS.

I agree heavily with Mark on the source modification issue.  Once you start
down that slippery slope you'll find yourself maintaining the other software
more than your own. :S

>I think there's room for a separate "release tool" that creates
>Changelog information, verifies all the files you are packaging in a
>tar.gz have been tagged, verify all source files include the appropriate
>license, verify all bugs worked are in a closed/fixed state (or
>according to some other policy) etc. I have a separate script I use to
>release scmbug that may be of interest.

Don't forget that not everyone uses ChangeLog.  In the BSD world it is
almost not used.

>> In my perfect world the integration glue uses only the published API of
>> the change-request tool (web service, socket connection, etc.). Hacking
>
>How do you handle in your perfect world upgrades in the published API
>when the glue has not been upgraded in the repository ?

I hope I am understanding correctly, but that's why you need to take the
data you have and make it agnostic to a specific piece of software, save
your own.  Also, APIs normally don't change out quickly under your feet,
well, at least it will not if the developer has some experience doing real
code.

>> CVS's lack of atomic commits will be rendered irrelevant when Subversion
>> replaces it as the de-facto standard for open-source projects. I am not
>> being religious here, I just can't see the world sticking with CVS when
>> there is a better tool available. (Of course, there is quite a bit of
>> inertia to overcome ...)
>
>I agree here. But this may not be an option for everyone.

Big advantage of CVS is the file hacking possibility.  I have used CVS for a
long period and even do/did some maintaining in FreeBSD and DragonFly, but
for the new launch of TenDRA I switched to Subversion and for the occasional
feature missing (diff -N) I haven't regretted it.
But Subversion can also be overkill for some people, remember that CVS uses
normal files so it in effect it is merely a client and daemon.  Subversion
has dependencies to APR and bdb at least.  Of course, with fsfs things will
change a bit.

>> >From the technical side, why a daemon? As I mentioned above, scmbugd is
>
>Primarily because Bugzilla's current public API is the globals.pl file,
>and I'm assuming other tools also lack a publicly accessible API. I'm
>calling functions out of globals.pl, rather than sent sql statements
>that assume a certain schema.

That's good, assuming a certain schema is a sure way to hang yourself.

>I had to add some new functions I'm planning on submitting for inclusion to
>Bugzilla as part of their API.  I prefer to wrap around other people's APIs
>with what you call a "glue to change-request API" today, rather than wait
>for everyone else to make theirs truly public (ala WebDAV). Since the
>assumption that the bugzilla source is uncompressed on each machine that
>hosts a CVS repository is a little far-fetched, I'm requiring that source
>only on the machine scmbugd runs.

DragonFly, FreeBSD, NetBSD, and OpenBSD all provide cvs in their base
install.  Patching this every time is cumbersome since a CVSup will replace
the files with the original ones again.
Of course, often they have a global NO_CVS make variable which disables
building it and installnig a custom one.

>As to why I picked a TCP daemon rather than a different service (e.g.
>WebDAV)... there's no WebDAV chapter in my Perl book, and with minimum
>research a barebones daemon was coded in less than a couple of hours (I
>was coding this over Spring break, needed it desperately and had the
>whole thing working over a weekend). I think some separation of a "glue
>to change-request API" is valuable, but the daemon could be replaced
>with a WebDAV service.

Just for the record, the repository and bugzilla software do not necessarily
have to reside on the same box!  I know a lot of split set-ups.  Also, I do
not use WebDAV anywhere nor will I install it, since I do not want nor need
it.  I find it less secure than using my repository over ssh.  But that's
just me. :)

-- 
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7  9D88 97E6 839B 2EAC 625B
http://www.tendra.org/   | http://diary.in-nomine.org/
All that we are is the result of what we have thought. The mind is
everything. What we think, we become...