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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
