New language discussion?
gerv at mozilla.org
Wed Oct 31 12:12:51 UTC 2007
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
> 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.
More information about the developers