I'm just idly taking a look at GNATS...

While the popular sentiment is "I'm too old for this shit", GNATS is one of those things that just want me say "I'm too young for this shit."

GNATS is an elderly GNU project which aims to be a simple bug tracker. And going with that definition, it succeeds. It is simple (too simple) and it is a bug tracker. One of its (former) ground-breaking features is that it can interface (as in "user interface") with many things, like The Web (!!) and E-Mail (sic!), but historically its interfaces are vi and emacs. And I have nothing especially against GNATS as it is - it's just that it's old and I feel like ranting.

Take a look at its source, for one thing. The "gnats" subdirectory where most of the action is contains over 80 files. From this list the 10 largest files are:

-rw-r--r--  1 ivoras  ivoras  257724 Oct 27  1999 ChangeLog.v3
-rw------- 1 ivoras ivoras 222020 Mar 6 2005 configure
-rw-r--r-- 1 ivoras ivoras 177515 Dec 10 2001 regex.c
-rw-r--r-- 1 ivoras ivoras 115150 Feb 24 2005 ChangeLog
-rw------- 1 ivoras ivoras 73306 Mar 6 2005 fconfig.c
-rw------- 1 ivoras ivoras 71387 Mar 6 2005 fconfigl.c
-rw------- 1 ivoras ivoras 63275 Mar 6 2005 getdate.c
-rw-r--r-- 1 ivoras ivoras 62777 Aug 4 2002 gnats.el
-rw-r--r-- 1 ivoras ivoras 40571 Nov 25 2002 query.c
-rw-r--r-- 1 ivoras ivoras 40247 Aug 30 2003 cmds.c

(don't fear the timestamps)

Of those, regex.c can of course be replaced with anything, fconfig*.c and getdate.c are yacc-generated parsers (and at least getdate can be replaced with strptime), gnats.el is the emacs "interface" and "query.c" and "cmds.c" are actually honest pieces of code doing something nontrivial, which is mostly string parsing and hand-dealing with the minutiae of its text-based (think: ports tree) database. It's like a parody of the Hello, world parody.

I will officially make it my mission to thwack anyone building his or hers own ad-hoc database of anything on the head from now on.

As for GNATS, if I ever achieve some proverbial quality time with it, I will probably rewrite it (surprise, surprise) with Lua and SQLite. I estimate it could be rewritten in less than 1000 lines in such a sane programming environment.

#1 Re: GNATS

Added on 2010-09-08T04:53 by Alex Botero-Lowry

GNATS stores data as RFC822 encoded messages, which means it supports arbitrary fields, that every language and it's brother knows how to parse. As a result of this writing tools that operate over it is pretty much trivial.


GNATS deserves _way_ more credit than it receives. It's thought of as this old piece of junk but it's actually incredibly powerful and flexible and built to be expanded and manipulated into anything you want. It has a very similar philosophical bent to GIT, in that regard.


#2 Re: GNATS

Added on 2010-09-08T08:15 by Lapo Luchini

I do agree: SQLite is *the* answer to most database problems. ;)

#3 Re: GNATS

Added on 2010-09-08T11:46 by Ivan Voras

I often hear about the supposed horrible complexity and inflexibility of SQL databases from system programmers and I think those who are religiously opposed to it should learn more about the topic. We are not talking about ancient IBM experiments from half a century ago (which, like all early experiments *were* overly complex and feature-challenged). Even the simplest modern SQL databases (like SQLite) offer much more flexibility than most projects need.

Think of SQL as a helper language with the same purpose as regular expressions (remember that regex is a language!). As noone sane today would implement its own regex-like parser, so noone should develop his own database (of course, exceptions exist in both cases). As regex strings are included in C programs, so can SQL strings be included - neither language is Turing complete by itself, both are (sort-of) declarative and require native functions to extract results of their operations.

As for the RFC822 frmatting of GNATS entries - I take it you haven't actually seen the raw text of the messages? It's not MIME multipart format, the RFC headers are *only* used to hold RFC fields, of which Subject, From and Date are actually used, and the rest of the entries are pretty much free-form formatted and require dirty parsing (see, e.g. how patches are parsed for the web interface and think about how would you parse the Audit-trail.

Yes, you can't use grep to search a SQL database, but you can't index text files with unique fields either.

#4 Re: GNATS

Added on 2010-10-03T02:24 by Henry

How about just going with something modern like RT. You can interface it with mail, web, db, etc. I've used it in the enterprise space and been very pleased with it. The largest issue will be munging the old data into it. That's just legwork and not related to choice of tracker.

And speaking of modern, why in the world did FreeBSD choose another ancient analogy to CVS with SVN. Git, and gitweb, are so far ahead. And it offers crypto authenticity from repo to release. Only signed CD images?, lol.

Why FreeBSD has, and is [apparently still], choosing the easy way out in these

two major cases is beyond me.

#5 Re: GNATS

Added on 2010-10-03T02:42 by Ivan Voras

Any recent solution would be fine replacing GNATS, but as for svn -- I must disagree; I find git overenginnered and almost unsuitable for use outside its circle of fans. Other DVCS-es are generally easier and IMO better than git (personally I use Mercurial much), but svn is practically a perfect match for a centralized project like FreeBSD.

#6 Re: GNATS

Added on 2010-10-03T20:31 by Henry

Hg is nice too. It seems to mostly be a competitor to git. Maybe a bit less techical curve to start. i would think git can surely be used in a centralized fashion, for lack of better words.. dumbed down. I've been searching for more threads where the cvs to (whatever) discussion took place but they seem to be few and short.

Not panning FBSD at all, love it! Hoping for more :)

With having seen a large RT install, might even try importing gnats locally in some free time.

Comments !