Update on bug system for OpenJDK

[Roger Calnan]

> I am confident that there will be more relevant extensions and boundary 
> systems developed by OpenJDK developers with a Java API, than in Perl.
	I suspect that the language won't impact the relevance of the extensions
but for us we are far more likely to find expertise in Java vs. Perl for the
set of people who will have an interest in deploying/maintaing and extending
the system.

> The bug system and other systems we are going to put in place for 
> OpenJDK will be managed by a group that has a lot of experience in 
> managing highly available application servers and Oracle databases.  
> It is  cost beneficial for the us to get hosting, management and 24x7 
> support if we chose a platform that is supported by this group. 
	I'd agree with Mark that MySQL would be fine for our needs,
but as with the first item when we work with the internal hosting groups
there will be far more experience/expertise with the Oracle database.

	With this and the Perl/Java question my position is that the choice
of the bug DB isn't going to make us succeed or fail, both can do the job.
However we want the lowest "cost" solution as we end up putting lots
of effort into the bug system it will distract us from JDK 8/9 etc. which
is where we will really succeed or fail.

>> - Access permissions -- Why do we need field-level access control?
>> What are the use cases for that?
> 
> The bug system is going to be used for OpenJDK and also for work done 
> on JDK for Oracle JDK. The bugs in the system could have some custom data 
> that is relevant only to Oracle and also to protect sensitive information that is 
> not to be displayed to users who are not OpenJDK members.
	Today we can likely deploy a solution without field level security,
however I think that there will be information (such as security descriptions
etc.) that we will want to share with the OpenJDK partners who are producing
a JRE for their platform where we will want to be able to share information
that won't go to the general OpenJDK developer population.  The more we
can have this information in the bug system vs. email the better.

>> - 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.
> 
> Yes, it is a very reasonable requirement to preserve the bug numbers, and 
> that is something to take into account. But I wonder, how critical is it that 
> bug numbers be preserved in a new system, especially if you could search 
> by old bug numbers anyway.
	mandating a prefix is ugly, I can see why it seemed like a good idea
but it not being optional is a pain.  From initial conversations with JIRA 
experts it looks like we could have jdk-4040458 etc. (ie. preserve the
existing numbering) and start all new bugs above jdk-8000000 but as
much as possible I'd say we hide/auto-populate the prefix.

> One value I could see for the prefix is to have prefix for different workflows, 
> JDK-bugs, CCC-issues, EFP-requirements etc. And also being open to the future 
> possibility that other JDK associated projects and components might use the 
> same infrastructure that we are setting up for OpenJDK.
	for CCC (this is the tool that we have used to track compatibility issues)
the requests have a 1:1 mapping with bugs and so we would want that the
CCC request for a bug 4040458 would have an equivalent ccc-4040458, but
no doubt that would cause JIRA some problems as we would be allocating
the IDs in a non-linear fashion.  EFP- (Engineering Feature Proposal, a
response to a requirement) makes sense as a feature could result in a
number of bugs and RFEs.

>> 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.
	I don't see that this analysis is far  off from the initial one we published.
Mohan's group have put in a lot more effort into the actual implementation and
I think that is what is swaying us to an answer more than biasing the results.

>> 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.
	agreed and JIRA/Bugzilla both allow that.  However if we have more
than a few engineers spending time on developing such systems we are
wasting our time as the end of the day we should be putting our efforts
into improving Java vs. the bug system each of which have lots of people 
who find developing bug systems interesting helping to improve them.  We
don't, we want a tool that just works.

> One of the reasons for looking for new systems for OpenJDK is to increase 
> our efficiency. 
	this is key.

> Choosing systems based on technologies we understand and 
> can control and having thousands of engineers that are experts is in line with that.
	again hopefully the bug system won't be our focus once we get going,
however these points are valid for the group that will be implementing and
maintaining the system moving forward.

> From the comparison based on our requirements one system comes out ahead, and that is JIRA.
	let's move this effort into the decision phase as this clearly we won't 
make a choice that pleases everyone, but we need a decision and move on.
We can't duck (avoid) a decision as we can with the netbeans vs. eclipse
vs. emacs question, luckily....

	Roger