New language discussion?

[Benton, Kevin]

> > We are currently working on a re-write of Bugzilla in C++ 
> as a part of
> > the EVS project (www.evscm.org) which is designed as a 
> platform for CM
> > systems rather than a version control tool.
> 
> Of all the programming languages, my top priority of least usability
> for a Bugzilla-like project would be: 1.) Assembler, 2.) C, 3.) C++
> 
> I am sure that choice of programming language was made due to the
> programmers knowledge and not with regard to the suitability for a web
> platform.

IMNSHO, the question of "do we move to a new language or keep moving
forward with what we have?" has been asked over and over.  The rub is
this: what does moving to a new language give us that we don't already
have and the corrolary, what is the return on investment if we move and
how will we be able to move faster because of the work done to move?
It's easy to argue that we like language x better than language y, but
that doesn't matter.  We have a working application in Perl today.  We
need to ask the hard questions in order to determine if the benefits
outweigh the risks, if the change will prove itself useful in a timely
manner, and if the change is made, at what point do we pull the plug on
changing if it hasn't happened "fast enough".

A much less preferred option is to encourage those that want to work on
the "new" language to do so on their own project.  This would further
split the resources to make Bugzilla into what it can be while it's
pulling resources away to a "new" project based on the old.  XEmacs and
Emacs have both had this issue in the past with gains and losses seen on
both sides.  In my view, I think both sides lost because development was
split and in some ways, has lost the benefit of the synergy between the
teams.  On the other hand, both sides won because each agreed to
disagree and go their own separate ways.  Users were given a choice on
which environment they preferred.  The drawback was that some wanted to
pick and choose feature sets from both but couldn't because the
development had diverged.  In my view, the result was a net loss.

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.  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.  This work is
already in-progress.  Another problem we've seen is the CGI will call
the same subroutine directly and indirectly a number of times to get the
same answer back each time.  This too is getting better, but it's got a
long way to go.

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.  Once the code support them, then they truly
will be add-on fields.  While we're doing field schemes that allow
administrators to select what fields are available by product, we're
also developing workflow schemes in the same methodology so that each
product can have its own workflow.  There are many different workflow
needs within our company based on the type of work being done.  Some
processes have an extra documentation step, some have an extra
incorporation step, and there are many others.  Not all products need
the extra steps so workflow schemes will allow us to assign those
workflows on a per-product basis.

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.  We're moving at the speed of business
requirements here and unfortunately, it's very challenging for us to
remain in sync with what the community is doing versus what our internal
needs are.  It's a lot of work for us to stay in sync with the tip and
do our own development with the risk that a patch we submit may not be
accepted by the community.  There are a number of things (like the
schemes discussed above) we need that really should be implemented
within Bugzilla core, but we need them before the community will be
ready to accept those changes (meaning more work for us to keep our
changes "up-to-date" while the community catches up with us).  Our
business requirements state that our field and workflow schemes must be
completed before the new year, yet, knowing that, there is no way we can
rely on the community to accept those changes into the trunk so we don't
have another issue with forking our code.  We've had internal
discussions that we'd be glad to contribute both code and test cases
(and Selenium tests to run those test cases) to prove out our
submissions, 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.  That burns a lot of
time up because we can't insert forward-looking code in a patch moving
bugs.versions to bugs.version_id.  We're trying to get to a point where
all the _id fields are dealt with in a uniform fashion so that custom
fields become less custom and more add-on.

I won't begin to hide that we have an agenda as a corporate customer and
contributor.  Yes, we'd like to help when helping moves us in a
direction that makes sense for our company.  I'm certain that there are
other companies out there that would do the same.  The challenge is, how
do we contribute in a way that is meaningful for the community while it
doesn't hog-tie us.  AMD spends significant amount of money each year
for Bugzilla development.  AMD would love to see some ROI on that
development by seeing some of that code contributed back to the core so
that as Bugzilla features are added, incorporating those back into our
code base is less of a "how much effort will it take to incorporate
that?" to "are we ready to upgrade again?"

I could go on but I'll stop here for now.


---
Kevin Benton
MySQL DBA #5739
Senior Software Developer
CAD Global Infrastructure Flow Services
Advanced Micro Devices
2950 E Harmony Rd
Fort Collins, CO  80528
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have
received this communication in error, please notify the sender, then
destroy any remaining copies of this communication.