New language discussion?

Max Kanat-Alexander mkanat at
Wed Oct 31 19:50:58 UTC 2007

On Thu, 1 Nov 2007 06:40:19 +1100 "Arthur Barrett"
<arthur.barrett at> wrote:
> It solves a particular business problem for us. [snip]

	Okay, this makes sense.

	For what it's worth, here's how I'd solve that problem and
still stay with Perl:

	1. Bugzilla could support SQLite, which would mean not having
to install MySQL.

	2. It's actually possible to compile perl apps to an .exe using
some applications. You could do this with every CGI. I have no idea if
it works with CGIs, but it couldn't hurt to try, I suppose. :-)

> I am not a fan of rewrites, and I'd only marginally call what we are
> doing a rewrite.  Release 1 will not re-implement the full feature set
> of bugzilla, but it will use the (latest) Bugzilla data model.  This
> means that for people who want a bug tracking system that "can grow"
> then they can start with ours that works "out of the box" and later
> install the "full" Bugzilla on top.

	Okay. So it's kind of like "mini-Bugzilla in a box". :-)

> I'm sure we'll market it as "data model
> compatible with Bugzilla, but that doesn't infringe any trademark I
> don't think.

	Yes, that is probably OK, although I'm not a trademark
authority for MoFo.

> Our main open source project is CVSNT, which was essentially a fork
> from CVS.  One of the main things that drew people to CVSNT initially
> was that the developers would accept almost any change and put it
> right into the next build within a few days.

	And the code hasn't gotten unmanageable? Perhaps CVS was
architected better than Bugzilla was architected some years ago.

> On the up side -  by only supporting defect
> integration to Bugzilla I know a lot of companies that have gone
> ahead with Bugzilla...

	Yeah, and we often point people at your software. :-) I know
that I'm certainly appreciative. :-)

Competent, Friendly Bugzilla and Perl Services. Everything Else, too.

More information about the developers mailing list