OpenJDK bug database: DRAFT Developer Workflow

[Peter Jensen]

On 01/04/12 16:15, Brian Beck wrote:
> On 1/4/12 12:00 PM, John Pampuch wrote:
>> If we "complicate the entire system" (I'm not sure it does), at least 
>> we could have a uniform view for all bugs for all engineers.
> I think it does.  More states is certainly more conceptual weight.  
> There are more states to define and police, and if the states don't 
> mean much for certain types of bugs, then there also have to be rules 
> about what the data means when looked at in the aggregate.
>
> It's also probably means that you have to do queries on the union of 
> some set of in-process states when looking for common things like all 
> the open bugs.
>>
>> Some bugs don't need to individually flip through all of the states, 
>> but there is a lot more information communicated for those that need to.
>>
> So there's clearly an element of personal taste here.  It also seems 
> clear that some bugs are more amenable to the "cause known", "fix 
> understood", "fix available" model than others.  The question is, what 
> is the common case?  I believe Iris did some analysis of the existing 
> bugster data and found these in-process states to be seldom used.  
> Maybe we can get her to share the data on this thread.

I think it's somewhat a matter of taste, but it is also a question about 
how formal we want the process to be.

One could imagine a process like:

New:            Filer to Support:      Hey, something happened, this 
doesn't look right!
Open:           Support to Dev:        Guys, this look like a real problem
Cause-Known:    Dev to Decision Maker: Information about cause now available
Fix-understood: Dev to Decision Maker: Suggestion for fix now available
Committed:      Decision Maker to Dev: Alright, go do it
In-Progress:    Dev to ?:              Okay we're starting now (and ETA 
information is available)
...

For most bugs, Dev and Decision Maker may be the same, or so close as 
not to matter.
For some bugs, decisions do get escalated to management. But in my 
experience the real processes is still not driven, or significantly 
influenced, by the intermediate bug states.

So, by adding what's essentially a DEV internal workflow, we're at least 
hinting at a process that we may not be willing to abide by!?
If there is a mismatch, then sooner or later, someone is gonna confuse 
the model for reality (e.g. draw conclusions based on unreliable data), 
or worse (try to) force reality to look like the model.

Of course, if we do want a formal bug evaluation process, then it 
becomes a question about how best to support it. In that case I would be 
much more positively inclined to uses defined states, rather than just 
state (i.e. data encode with tags or otherwise).


Note: In-progress is also, in my opinion a DEV internal state, and I 
don't know exactly what to make of it. Especially, without the other 
intermediate steps, it's hard to guess when exactly you get to be this 
state.As far as I can tell, there is no hand-off, no actions that are 
triggered by this transition, and I don't know if I can trust the 
information being conveyed or what to do with it.


>
> Brian.
>>
>> On 1/4/12 11:34 AM, Richard Bair wrote:
>>> It sounds like you could make use of the tags as well. But I don't 
>>> agree at all that it "sucks big time", and I have certainly not 
>>> heard this complaint from anybody else. So yes I agree it is a 
>>> personal opinion, but with tags you have the liberty to categorize 
>>> your bugs in any way you see fit. Why should we complicate the 
>>> entire system when for most people the current states are sufficient?
>>>
>>> Richard
>>>
>>> On Jan 4, 2012, at 11:23 AM, Phil Race wrote:
>>>
>>>> I've not read the entire thread on developer workflow (I've got 
>>>> thousands of emails to
>>>> read after being out a month, but  I beg to differ on this point at 
>>>> least :
>>>>
>>>>> To give even more context to this, we haven't missed these sub 
>>>>> states at all in JavaFX.
>>>> Don't make it sound as if that's a univeral view because its not. 
>>>> Its a personal opinion
>>>> and here's mine :
>>>>
>>>> The Jira config we have on FX sucks big time. When I've complained 
>>>> I'm told its
>>>> because we use it more or less out of the box. I hope we don't 
>>>> repeat this mistake.
>>>>
>>>> I find states other than "open" to be invaluable in bug management, 
>>>> particularly as an engineer.
>>>> Maybe some people see no problem with a big morass of "open" bugs 
>>>> but I feel proper bug management
>>>> needs more than that. And I do not have time to re-read the 
>>>> commentary of every bug in my queue to know
>>>> which ones I evaluated  etc. ( evaluated in the sense of "cause 
>>>> known" and "fix understood), not
>>>> just "triaged". Instead I can sort by state.
>>>>
>>>> -phil.
>>>>
>>>> On 01/04/12 10:36 AM, Richard Bair wrote:
>>>>>> [snip, snip]
>>>>>>
>>>>>>> I don't see how asking a question relates/compares in any way to 
>>>>>>> having clearly defined states like "cause known" or "fix 
>>>>>>> understood". And of course you never know ALL of the 
>>>>>>> implications - "fix understood" doesn't imply absolute knowledge 
>>>>>>> of every nuance, just as actually fixing the bug doesn't imply 
>>>>>>> you know ALL the implications of the fix you've committed.
>>>>>>>
>>>>>>>
>>>>>>>> Management would be much better served by updated estimates and 
>>>>>>>> risk
>>>>>>>> evaluation. I've yet to meet a manager who, deadline looming or 
>>>>>>>> not,
>>>>>>>> would make a decision to commit-to-fix or reject a bug based on 
>>>>>>>> these
>>>>>>>> states.
>>>>>>>>
>>>>>>> The states convey initial information used to discuss estimates 
>>>>>>> and risks pertaining to the bug. If every bug is just "accepted" 
>>>>>>> then the discussion has to start with "where are with this bug? 
>>>>>>> do we know what's causing it? do we have a fix?" instead of "I 
>>>>>>> see the fix is understood, what do we need to do before pushing 
>>>>>>> it? Is it a high or low-risk fix?"
>>>>>>>
>>>>>>> Just my opinions - YMMV
>>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>> After countless hours (maybe years!) of conducting bug review 
>>>>>> meetings, my experience is that *every* bug has a story.  Nobody 
>>>>>> is content to describe their work as "fix understood" or "cause 
>>>>>> known".  And without the story, reviewers can't make useful 
>>>>>> decisions about risks, rewards, estimates etc.  The story is (or 
>>>>>> should be) captured in the commentary and it must be read.  I 
>>>>>> can't think of any useful decisions that an RTeam or Eng. Mgr. 
>>>>>> could make simply by looking at a "cause known" or "fix 
>>>>>> understood" status.
>>>>>>
>>>>>> Perhaps these statuses are useful for individual engineers to 
>>>>>> sort their bugs, but I don't see them helping any of the 
>>>>>> management functions.
>>>>>>
>>>>> To give even more context to this, we haven't missed these sub 
>>>>> states at all in JavaFX. Most of us are ex-JDK developers, but in 
>>>>> JavaFX we have been using JIRA for 3 maybe 4 years now. The states 
>>>>> we have are:
>>>>>
>>>>>     New
>>>>>     Open (Not my favorite term)
>>>>>     In Progress
>>>>>     Reopened
>>>>>     Resolved (Engineers resolve)
>>>>>     Closed (SQE closes after verification)
>>>>>
>>>>> There are a couple others in our JIRA system, but we don't use 
>>>>> them. To be honest, I've not found a great deal of utility out of 
>>>>> Reopened either, but it hasn't complicated my life much so I'm OK 
>>>>> with it.
>>>>>
>>>>> Then there are a number of different "Resolutions" which indicate 
>>>>> how we resolved it.
>>>>>
>>>>>     Fixed
>>>>>     Won't Fix
>>>>>     Duplicate
>>>>>     etc etc
>>>>>
>>>>> The only piece of information that we've felt pain over not 
>>>>> having, is "Fix Available" or some other method for tagging the 
>>>>> issue with what repo the fix is available in. I'd prefer not 
>>>>> having a state for this, but just tag the issue (so it is still 
>>>>> searchable), and have the tagging done automatically when an issue 
>>>>> is pushed into a repo.
>>>>>
>>>>> As Brian said, I don't see any value from a bug court or release 
>>>>> team perspective in having more states or sub states, and as an 
>>>>> engineer I wouldn't ever use them. However as an engineer, if you 
>>>>> find them useful, you can make use of the custom tag feature in 
>>>>> JIRA and keep this additional information in a way that is easy 
>>>>> for you to query and understand. Likewise if a team decides they 
>>>>> want additional categorization (for example, in the JavaFX UI 
>>>>> Controls team we would add a tag ScrollPane for any issues 
>>>>> involving the ScrollPane control, etc, and a single Issue might 
>>>>> affect multiple controls and so forth), then that is perfectly 
>>>>> reasonable as well. But from a higher level release team 
>>>>> perspective and from a don't-overcomplicate-my-life perspective 
>>>>> and from a universal-process-decision perspective, I much prefer 
>>>>> just having a short list of states.
>>>>>
>>>>> Thanks
>>>>> Richard
>