OpenJDK bug database: DRAFT Developer Workflow

[Volker Simonis]

Hi Iris,

please see my comments inline..

On Wed, Dec 14, 2011 at 9:39 PM, Iris Clark <iris.clark at oracle.com> wrote:
> Hi, Volker.
>
>> nice to hear that somebody is working on this.
>
> Thanks!
>
>> I have some questions around end user / external user access to the new
>> system:
>>
>> 1. Who will be able to open a new bug/RFE?
>>  a. everybody
>>  b. registered users only (with some trivial click-trough registration)
>>  c. only special roles as defined in the OpenJDK bylaws (i.e. Participants,
>>     Contributors, Authors, Committers, Members..)
>>
>> I would strongly vote for variant a. or b. but if you choose variant c. at
>> least every "Participant" (i.e. everybody who subscribed to an OpenJDK mailing
>> list) should be able to open new bugs/RFEs.
>
> Right now, bugs.sun.com requires (b), minimal registration.  There are some
> who believe that that bar is too high and would prefer (a).  (c) is not on the
> table.
>
>> 2. Who will be able to change bugs/RFEs?
>>
>> This is somewhat related to question 1. Of course I understand that this will
>> have to be handled more restrictive, but at least commenting on a bug should
>> be handled as liberal as possible (i.e. at least as liberal as in the answer
>> for 1).
>
> Define what you mean by "change"?
>
> - Provide a comment similar to what we have on bugs.sun.com?
>
>  As you speculated, the answer would depend on what is decided for your first
>  question.
>
> - Provide an evaluation, update the bug's status, and other development
>  activities?
>
>  All OpenJDK Committers will need to be able to update bugs.  OpenJDK Authors
>  may also be able to make limited set of changes as appropriate for their
>  role as Author.
>
> (I plan to provide more details when I get to the "Roles" section of the
> document.)
>
>> 3. Will it be possible to "subscribe" to a bug/RFE in order to get notified of
>> any changes?
>>
>> Again a crucial feature for me which should be handled as liberal as
>> possible. The author of a bug should be placed automatically on the
>> subscription list (which would of course require some kind of registration -
>> e.g. with the credentials of a "Participants")
>
> Yes.  JIRA provides mechanisms to vote on bugs and receive notifications.
> Both of these options will be available to the set of users identified by the
> answer to question 1.
>
>> 4. Will newly entered bugs/RFEs be immediately visible with a valid, immutable
>>    Bug ID (i.e. will they have status "Dispatched")
>>  - As you probably all know, currently new bugs filed from outside Oracle only
>>    get a temporary Bug ID until they are evaluated and promoted by somebody
>>    inside Oracle (which can take weeks..). I think this is simply a "no-go"
>>    for a real open source project.
>>  - Even bugs filed by Oracle employees need a day or more until they become
>>    publicly visible. Will this improve with the new system?
>
> All newly entered bugs/RFEs will be immediately visible.  Bugs submitted by
> OpenJDK Committers will be part of the Developer Workflow.
>
> I am currently investigating how we should handle end-user bugs (bugs which
> are entered in bugs.sun.com).  It is clear that they'll also be immediately
> visible; however, because those bugs tend to require more heavy triage, I'm
> exploring the idea of having them in another JIRA project with parallel
> ontology.  This would allow us to provide a workflow which is customized to
> their triage needs and to provide the additional guidance end-users already
> have when submitting bugs via bugs.sun.com.
>

I personally don't think that two parallel JIRA instances will be
particularly useful. They will be just a constant cause of confusion.
Because eventually you'd have to transfer bugs from the "end-user" bug
system to the "real" bug system. And even if you'd somehow manage to
keep the bug ids unique between the two systems, you would still have
two systems with all the drawbacks:
 - which system to search (before entering a new bug)
 - in which system to track the bug
 - you'll have to keep the bug content in sync between the two systems
(otherwise, if you just move the bug from one system to the other,
links to the original bug won't be valid any more)

So please stick to one system if possible. You could for example just
introduce a new state "UserBug" in the workflow which comes just
before "Dispatched".

Regards,
Volker


> Thanks,
> iris