[Python-Dev] tracker status options

[R. David Murray]

On Tue, 24 Mar 2009 at 21:27, "Martin v. Löwis" wrote:

>>     o consensus needed
>>     o test needed
>>     o patch needed
>>     o patch needs work
>>     o patch review
>>     o commit review
>>
>> The first of these additional items is equivalent to your bullet item
>> above.  I would propose that the issue, regardless of whether or not
>> it is a bug fix or a feature request, goes into 'consensus needed'
>
> Well, there is always the "unset" state, which means "not triaged".
> So if you propose that this should be the default initial state,
> I'm opposed.

No, I was not suggesting it be the default state.

> Instead, would it help to add a "confirmed" state? For a bug, that
> would mean that it was successfully reproduced; for a patch, it
> was confirmed as desirable.

So, 'confirmed' instead of 'consensus needed' (or confirmed/approved,
to cover feature requests), and 'patch is appropriate' that comes...I'm
not quite sure where?

> If the person performing triage cannot confirm the bug, they should
> reject the issue (or recommend rejection, in case they are unsure).
> Somebody performing triage should never conclude with "I don't
> know"; this would be time-wasting.

The cases I was considering are cases where in the comments on the ticket
there is disagreement either on whether or not the bug is a bug or (more
often) whether or not the feature is desirable, and at the patch stage
whether or not the patch is the appropriate fix.  I think currently
things sit in 'patch needed' until consensus is reached on the patch,
but I haven't watched enough tickets progress yet to be sure :)
Adding another stage here may be more confusing than it is helpful,
seeing as I can't really figure out where it would go.

Did I guess correctly that the process for "recommending rejection"
is to set the stage to 'commit/reject', the resolution to 'invalid'
(or whatever is appropriate) and the status to 'pending'?  That
seemed to work for the issue I did it to, in that someone came
along and closed it shortly after that.

> If, for a bug, the reviewer disagrees that it would be a bug if the
> behavior actually exists, then the issue should be closed (resolution
> not-a-bug/invalid). If the reviewer agrees that it would be a bug,
> but fails to reproduce it, a test is needed.

OK, so I guess I now understand how the current workflow is supposed to
work: if its stage is 'unassigned', then it hasn't been accepted as a
bug/enhancement yet, and triage should make that accept/reject judgement.

The tricky bit here for me is that I, as a new person doing triage,
don't always feel comfortable in passing judgement on a bug or feature
request.  So what would be the mechanism for a triage person to request a
"passing of judgement" from someone with more experience/authority?  Post
to python-dev?  Given such a mechanism, I think I would be comfortable
with the current workflow, with the expectation that I would need to
call for assistance less and less frequently over time, and ultimately
only for those things where discussion among the devs really is needed.

Hmm.  Maybe I should write a short "guide to performing triage" and
post it for feedback.

--
R. David Murray           http://www.bitdance.com