New language discussion?

[John P. Fisher]

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 
conversation?

thanks for any comment

John Fisher

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 
>