Old Discussion: Python Implementation? (Bugzilla:Languages)

[Kent Rogers]

I've been doing Bugzilla development and admin'ing an installation for over
5 years and originally I didn't think a lot about this post.  It seemed
like somewhat of an outrageous idea, but as I continue to wait for 4.4,
something that struck me in this last reply (which I also thought of right
before I read it):

  "It also likely shrinks the available pool of potential contributors.
  This may lead to fewer acceptable patches, fewer candidates to carry the
  torch when existing maintainers move on, etc."

This suddenly seems to be an issue and AFAICT, it appears that Bugzilla is
on the decline. :-(  I have no data, but contributors seem to be down and
releases taking longer.

I have shied away from contributing myself for the last couple years for
various reasons, some that I suppose are attributable to Perl and some that
definitely aren't.

4.4 was supposed to be released months ago.  4.4rc2 finally came out in
February but I have not heard *anything* about the prospects for the final
release since then.  I don't hang out on IRC, but I don't recall anything
being posted here, on the bugzilla.org web site, or on the Bugzilla Wiki.

The Roadmap on the Bugzilla Wiki hasn't been updated since 2010 (and
doesn't even list 4.4), and the IRC Meeting page on the wiki lists the next
IRC meeting as taking place on 2/15/12!

I'm not saying the proposal should necessarily be considered (although I'd
use Python if I were starting from scratch), but I wanted to give feedback
based on my observations over the last year or so.

-Kent

On Thu, May 16, 2013 at 01:18:43PM -0700, Matthew Bogosian wrote:
> It sounds like the landscape has changed since the proposal to consider languages/architectures was first raised. I am reluctant to take it on if there is little interest. There are plenty of bug trackers out there, so I'm not sure the world needs another.
> 
> I should say that I don't doubt that Perl or COBOL or whatever is "maintainable" indefinitely, but I'm not sure that's the point. Among the problems I was trying to solve was that (IMO) Perl requires a great deal of time and expertise to fully grok.* This leads to more project-specific, extra-language overhead (e.g., more complex coding conventions, more complex change processes, increasingly complex abstraction layers, etc.). It also likely shrinks the available pool of potential contributors. This may lead to fewer acceptable patches, fewer candidates to carry the torch when existing maintainers move on, etc. I realize there are (currently) many commercial entities that have put a bunch of eggs in the Bugzilla basket, but this does not guarantee immortality.
> 
> Thanks for everybody's input. I will let sleeping dogs lie for now, but if the mood changes in the future, maybe I can be of assistance....
> 
> 
>     --Matt
> 
> * Please keep in mind my own bias. I'm still unclear what "good" Perl looks like. It is undeniable that Perl is popular, but there's a difference between being hacking something that works, and engineering something that is clean, elegant, understandable by outsiders, and only as complex as it needs to be. It feels like proficiency in Perl and in many things written in it requires more effort than other architectures. I accept that I could be wrong about this.
> 
> 
> On Apr 30, 2013, at 17:42, Simon Green wrote:
> 
> > On 01/05/13 09:52, lindsay wrote:
> >> Perl 5 cannot be maintained for another 20 years.
> > 
> > Says who? Perl 5 is still actively developed and maintained, just as
> > much as any other modern development language.
> > 
> >> If your plan for Bugzilla's progress is to have Bugzilla communicate via
> >> RESTful interfaces (or whatever replaces REST), then yes, the codebase
> >> inside those interfaces can be with us for a great many years.
> > 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=866927
> > Enhance Bugzilla WebServices to allow data access using REST
> > 
> >> If your plan
> >> for progress involves a fair bit of extension to the core codebase, then a
> >> plugins structure would be a good investment.  Python has a good story when
> >> it comes to plugins.
> > 
> > Bugzilla's extension framework is not great, but it is pretty good. It
> > does about 80% of what bugzilla.redhat.com (which I help maintain) needs
> > it to do.
> > 
> >> So I think that's the issue.  Is the core stable/done, or will it grow
> >> significantly ?
> > 
> > It definitely is not 'done'. There are 2,353 open bugs in the upstream
> > project, and while all of them probably won't be implemented, a lot of
> > them will be.
> > 
> > In all honesty, I think porting Bugzilla to another language is a bad
> > idea. Bugzilla is 14½ years old now. I'm sure writing a new bug tracking
> > system from scratch (with a converter of course), is going to be better
> > than trying to keep up with the constant changes of the Bugzilla code base.
> > 
> > This of course, is no small task.
> > 
> > -- 
> > Regards,
> > 
> > Simon Green
> > Software Engineer
> > Red Hat Asia Pacific Pty Ltd
> > -
> > To view or change your list settings, click here:
> > <http://bugzilla.org/cgi-bin/mj_wwwusr?user=mtb19@columbia.edu>
>