OpenJDK bug database: DRAFT Developer Workflow

[Alan Bateman]

On 13/12/2011 19:39, Iris Clark wrote:
> :
>
> 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.
>
Iris - just a couple of initial comments/questions:

Not strictly workflow related but can you expand a bit on the "where" 
list mentioned in the description of Fixed? This is clearly very 
important when changes accumulated in integration forests are pushed to 
master but less critical (in my view) when changes propagate to other 
integration forests. I would also suggest that our collection of 
integration forests isn't fixed and will change over time so it's not 
completely clear to me how in sync the "where" will be.

The quality function is currently mentioned as moving bugs from Fixed to 
Closed. I will think it will be great to have quality folks working 
openly in OpenJDK and I'm just wondering if this need to be separated 
out into a different role for the purposes of work flow.

Same thing for the integrator function who I will assume be responsible 
for ensuring that the bug database is updated when changes are pushed to 
the master forests.

The sub-statuses on Closed seem too generous to me. I will guess that 
having the choice of "Not a Bug", "Not Accepted", and "Not our bug" will 
lead to minor spats. In terms of transitions then I assume it will be 
possible to change these at any time - for example if someone 
incorrectly closes a bug with substatus Fix Failed then I assume we can 
change it in the event that it's just a misunderstanding.

Understood: In Dispatched description it describes Understood as: " This 
bug is either something which will be fixed as part of other work 
currently being conducted (but not quite a duplicate) or this bug was 
created specifically to describe planned changes.". Later in the 
"Understood" section it defines it as "Sufficient investigation has been 
preformed to gain a basic understanding of how this bug/feature request 
should be addressed. There is no requirement that an actual solution be 
known at this time". The latter is closer to what I would expect it to mean.

I look forward to seeing the Multi-Release section expanded. That's 
critical to how we work in OpenJDK.

-Alan