Steven Parkes wrote:
It wasn't really about having a list of needs clarification. It was more
about bounding open. I suppose it's my product development side showing.
Generally we tried not to leave issues open indefinitely, for fear of
not getting back to a customer. Perhaps there's nothing comparable in
the ASF model.
Just because you've gotten back doesn't mean the issue is gone. It
sounds like the list we might need is of new issues that have not yet
been responded to. So perhaps adding a field indicating whether a bug
is new, or has been responded to should be added. Then we could try to
keep the queue of new, as-yet-unresponded-to bugs small. Would that help?
A reviewer is someone whose opinion influences a committer.
Mostly thinking about Jira state issues. If Jira state can be affected
by more than committers (for example assigning to oneself, as a member
of lucene-developers), should reviewers still just provide comments on
other issues and leave it to a committer to bounce patches? Don't mean
to make too much of this; perhaps it's obvious what one should and
shouldn't do. Only trying to figure out how reviewers can contribute
without going too far.
If someone is confident enough to reject a patch and they're not a
committer, then they should still reject the patch. If someone else
disagrees with that judgement, then they can re-submit it.
Well, if patch available is added, there's always the issue of moving
issues into that state but I suppose contributors, if they're still
around, will do that themselves.
So is Hadoop's workflow acceptable to all?
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
