Old Discussion: Python Implementation? (Bugzilla:Languages)
mtb19 at columbia.edu
Thu May 16 20:18:43 UTC 2013
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....
* 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.
> 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.
> Simon Green
> Software Engineer
> Red Hat Asia Pacific Pty Ltd
> To view or change your list settings, click here:
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4237 bytes
Desc: not available
More information about the developers