Update on bug system for OpenJDK

[mark.reinhold at oracle.com]

2011/5/24 12:48 -0700, mohan.pakkurti at oracle.com:
> As you know from earlier discussions, we have been evaluating Bugzilla
> and JIRA for bug management for OpenJDK.
> 
> I have posted the latest comparison notes here:
> 
> http://cr.openjdk.java.net/~mo/openjdk/bugsystem/BugzillaJIRAComparison.pdf
> 
> It would be great to hear your comments on this.

Thanks for pulling all this information together.  Here are some comments
and questions about it.

  - Implementation language -- You list Bugzilla as being at a
    disadvantage here because it's written in Perl.  I don't think the
    implementation language is all that important.  Regardless of which
    system we choose I doubt we're going to customize it much, since
    customization inevitably increases the cost of doing the next version
    upgrade.

  - Required environment -- Why is an Apache+CGI/mod_perl environment
    worse than standalone, or WAR/EAR?  (Bugzilla runs just fine, by the
    way, under other web servers such as lighttpd.)

  - Database -- Why is it a major concern that Bugzilla doesn't support
    the Oracle database?  If MySQL is good enough for bugs.mozilla.org
    then it's almost certainly good enough for us.

  - Web-service API -- A critical sub-question here is whether the API
    exposes all of the data and every action that's available through the
    browser interface.  It must be possible, in principle, to do two
    things: (1) Extract all of the data in order to mirror the bug
    database on another system, and (2) Create an alternative client
    interface that has all the functionality of the browser interface.
    To what degree do Bugzilla and JIRA support these goals?

  - CLI -- For Bugzilla there's PyBugz [1], an actively-maintained Python
    interface to Bugzilla which includes a CLI.

  - Identity -- I don't understand why Bugzilla is listed as requiring
    third-party identity plugins.  Bugzilla has full support for LDAP, a
    recognized industry standard.  Is that not sufficient?

  - Access permissions -- Why do we need field-level access control?
    What are the use cases for that?

  - Query language, Reports, Actions, Notifications -- The color codes of
    the headings at the top of these sections indicate that Bugzilla has
    "minor concerns and deficiencies", but you don't say what they are.

  - Preservation of bug ids -- You say that Bugzilla can retain bug ids,
    and that JIRA might be able to retain bug ids ("but needs work") and
    in any case will force a project prefix ("JAVA-").

    I consider it a hard requirement that we be able to retain existing
    bug ids -- not just have special fields that cross-link to them, but
    actually retain them.  These ids have been used in so many places for
    so many years that not retaining them is going to be a significant
    ease-of-use issue.

    I also think JIRA's mandatory bug-id project prefix is, well,
    ridiculous.  Why must we type "JAVA-" (or "JDK-", or whatever) in
    front of every single bug number?  What value does that add?  The
    prefix convention may well be useful in a large community with many
    unrelated projects, but that's not what OpenJDK is.

  - Workflows -- Why is supporting multiple workflows a hard requirement?
    What are the use cases?  Are there ways to support those use cases by
    means other than separate workflows?

  - Integration -- I don't understand why Bugzilla is listed as being at
    such a disadvantage here.  Can you please elaborate?

Overall, I have to agree with previous comments to the effect that this
analysis seems, so far, to be somewhat biased in favor of JIRA.  I look
forward to seeing answers to the questions I've raised above so that we
can make as objective a decision as possible.

For the record, I'm not a huge fan of either of these systems.  In the
end I think the most critical requirements are an underlying data model
that meets our needs together with a complete and open web API so that
alternative clients and boundary systems can be constructed -- as they
inevitably will.

- Mark


[1] https://github.com/williamh/pybugz