New language discussion?

[Gervase Markham]

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 if we don't change the standards by
> which we code.  So, I suggest that we look at the real issue - how do we
> design our code so that it doesn't look and feel like procedural
> spaghetti?  Having SQL in the CGI, for example is a great example of why
> you don't want to repeat yourself again (:-).  Moving the SQL into
> modules that deal directly with the database (DAO) makes the most sense
> to me because then, there is only one place to maintain with regard to
> the back-end and it's easy to change out if needed. 

You see, five years ago, people weren't doing this - or it wasn't nearly 
as well known as best practice. Bugzilla is improving all the time as 
people's understanding of how to write web apps improves, and that can 
only be a good thing. But we'll never be perfect, because perfect is 
always changing.

> We're (AMD) actively working on a radical shift in the way that "custom"
> fields are being done by providing a field scheme model of implementing
> "custom" fields.  We prefer to call those "custom" fields "add-on"
> fields rather than custom. 

How do they compare to the various other ways of implementing custom 
fields that were proposed when we originally did them?

> Frankly, our number one concern with contributing code back to the
> community is the length of time it takes to go from contribution to
> approval in combination with the risk that our change set(s) won't be
> accepted by the community. 

Contributing has concerns; forking has other concerns (like increased 
maintenance). You have to do what is right for you and your business. 
That's fair enough.

> however, we've also seen resistance to our methods of
> making changes because we need to package things in chunks that we feel
> reviewers can review and approvers can approve. 

Do you really think this is unreasonable?

It's always the case that one guy working on his own with complete 
freedom can work faster than when he's using a team process with checks 
and balances. It's one of the downsides of collaboration which have to 
be measured against the upsides of (hopefully) increased code quality 
and more future-proof design, etc.

Gerv