New language discussion?
John P. Fisher
john.fisher at znyx.com
Wed Oct 31 18:12:54 UTC 2007
excuse me for butting in here, as a non-contributor to the public code
base. I have a bugzilla installation so modified and hacked that I gave
up on updates and just forked it. This discussion sounds very
professional and sensible, and illustrates, IMO, what happens with code
bases that become large and mature. You guys are all smarter than I, so
I won't pretend to any solution inside the main tree of bugzilla code.
I'd like some feedback, on my future plans for our bugzilla. We are a
small commercial software outfit ( linux - C ) with no IT department (
thank goodness). Our bug base has about 5000 bugs in the main product.
We are in the telephony-aerospace biz, so customers require separate
code trees sometimes, and years of support for any release. So we have
features like branches and cloned bugs and version-fixed-in to
accommodate. We don't use any of the whiteboard-time-tracking stuff, and
I have lost track of the current feature set ( since I can't use it anymore)
gab gab gab anyway, I just can't see going forward with perl for a
web-based app that needs custom fields and life-cycle changes. So I
looked around and PHP is very well supported, but Ruby has a far better
object orientation and database support, so it looks to me like a
re-write in Ruby would give the best results. In reading this thread, I
am a little puzzled that it wasn't considered- perhaps I just missed the
thanks for any comment
Gervase Markham wrote:
> Benton, Kevin wrote:
>> As we all know, Bugzilla is implemented in Perl and the codebase is
>> getting better as we move to a more object-oriented model where
>> persistence is done at the proper layers.
> Indeed. Several years, ago, we asked the same question - rewrite or
> incrementally fix? The rewrite, Hixie's Bugzilla 3, didn't happen; Myk
> argued for incrementally fixing, and the code now is much better than
> it was. It seems to me that the arguments now are even more in favour
> of incremental improvement than they were then.
>> There's a lot of work to be
>> done, but no matter what language is chosen, it's possible to wind up
>> with the same problems we have today
More information about the developers