New language discussion?
arthur.barrett at march-hare.com
Wed Oct 31 23:17:50 UTC 2007
> 1. Bugzilla could support SQLite, which would mean not having
> to install MySQL.
It's only single user though - which may work since Bugzilla is
stateless but could easily bite at 9a in the morning when everyone logs
in, or at 6p when everyone is finishing for the day - particularly when
integrated with CVSNT so checkin comments are going to the Bugzilla
db... Its far more common though that "customers" request "will it work
with Oracle" though DB2 is also reasonably frequent...
> 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 have seen this, but hadn't really connected the two. I suspect that
since no one else has done it already it may be harder than it sounds -
and for now limiting the scope to a few functions and limited optios is
easier to deliver and test. But it's an interesting option - thanks for
> Okay. So it's kind of like "mini-Bugzilla in a box". :-)
Yes - though it has scope to grow based on demand - I guess I'd
eventually like to see 80% coverage of the top 80% used functions.
> And the code hasn't gotten unmanageable? Perhaps CVS was
> architected better than Bugzilla was architected some years ago.
We find that most peoples changes are fairly isolated - and they just
want "their change" added. Giving write access to the repo means they
are more likely to stay up to date with the project later since their
change remains in there. I am trying to encourage greater use of
"enable my feature with preference x". Since 2.5.01 we've introduced
some very nice 3GL triggers that can do a lot more than the Perl ones
previously could - so that's a solution that's easily isolatable, but
usually peoples changes are in the core.
> Yeah, and we often point people at your software. :-) I know
> that I'm certainly appreciative. :-)
More information about the developers