OpenJDK bug database: DRAFT Developer Workflow

[Martijn Verburg]

Hi Iris,

Awesome that this is being worked on and I know defining these
workflows can be a bit of a thankless task :-).

I'm going to approach it from a slightly different angle, but this
angle is really dependant on who has
access to the bug database (as Volker mentions). I'm assuming the
general public, assuming they have
a login so the original submitter can be contacted.

The proposed workflow is great because it does two important things:

1.)  It makes it really easy to migrate the existing data
2.)  Existing OpenJDK committers will be able to understand it easily

However, some of the naming is not what I've seen commonly used on
projects, and there's
therefore a risk that outsiders (i.e. The general public, which are
likely to be your most numerous
user) are going to misinterpret the statuses and cause havoc like a
pack of Otters.

---

My suggestion is to compromise and enhance the naming of these
statuses so that they're in line with
the more common nomenclature used in many projects today.  This could
be done either via a
description or the use of a subtext.

So perhaps:

Dispatched --> Dispatched (Open/Opened/Reopened)

Accepted --> Accepted (Verified)

Understood --> I share the same reservations as David on this one, I
don't think Understood is clear
                         In JIRA you can link issues either as
parent/children or as siblings, so having a status
                         that indicates it's part of another fix is
not necessary.

Fix in Progress --> Fix In Progress

Fixed --> Fixed (Resolved)

Closed --> (Closed)

Incomplete --> I'm not sure if this is required?  Typically a Bug or
RFE will stay in an Open status
until it it gets the details it needs.  The Assigned To field and the
comments are usually sufficient to
point out that someone is expected to give information before moving
the issue on.  Often a rule
can be put in place to auto-close open issues after X days if original
submitter does not supply
extra information, e.g. Closed (Not Reproducible or Insufficient
Information given).

---

I'm also a little confused about the QA steps setting closed sub
statuses.  I'm more used to a
workflow where a bug or RFE is Resolved and then only Closed once the
fix has been tested/verified.
Sometimes a Closed issue does in fact not fix the problem, in that
case it can be either OK to
ReOpen that issue or submit a new issue and link it to the old one.

---

That's my 2c for now, overall I think it's a great start and that I'm
glad you've thought carefully about
the migration aspects. Thanks again for working on this!

Cheers,
Martijn

On 14 December 2011 08:39, Volker Simonis <volker.simonis at gmail.com> wrote:
> Hi Iris,
>
> nice to hear that somebody is working on this.
>
> 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.
>
> 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).
>
> 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")
>
> 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?
>
> Regards and please keep on pushing this,
> Volker
>
> On Tue, Dec 13, 2011 at 8:39 PM, Iris Clark <iris.clark at oracle.com> wrote:
>> Hi!
>>
>> I'm defining requirements for the OpenJDK bug database [1].  As one
>> would guess, it's not easy.  We have more than 15 years of data,
>> process evolution, and supporting tools that we need to consider.
>> Opinions on the effectiveness of existing process and tools vary.
>> Many people with different roles (end-users, developers, quality,
>> release management, etc.) need to be able to access the system.
>>
>> I've written a preliminary draft of what the pilot workflow for bugs
>> and RFEs might look like.  It is based on the existing bug system with
>> modifications to omit portions that aren't used.  There is no
>> requirement that we stick closely to this draft, though any changes
>> will need to consider the impact on data migration.  It still needs
>> quite a bit of work.
>>
>>  http://cr.openjdk.java.net/~iris/jira/JIRAforOpenJDK.html
>>
>> Please send feedback/comments to this mailing list.  I'll provide
>> regular updates as feedback is incorporated and I fill in other
>> sections of the document.
>>
>> Thanks,
>> iris
>>
>> [1] http://mail.openjdk.java.net/pipermail/announce/2011-October/000112.html