lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <>
Subject Re: jira workflow
Date Tue, 17 Oct 2006 19:57:24 GMT
Steven Parkes wrote:
> My main concern is that things get lost in lists that grow without
> bound.

I've never been to concerned about the size of the open bug list.  It 
can be searched, if one wishes to find whether there's already an issue 
before filing a new one.  The lists I try to keep small are those that 
are assigned to a contributor and those that are scheduled for a 
release.  The list of open issues forms the universe of possible 
directions the project might take, and hence reasonably might be quite 
large.  Assigned and scheduled issues are the direction it's taking 
right now.

> That leaves, among other things, concrete bugs, irreproducible bugs,
> feature requests, and this blue-sky-y kinda stuff w/ or w/o patches. The
> Issue Type might handle some of this. Do we want to classify the
> half-baked stuff as a feature request? (And is the reporting good enough
> to make it easy to ignore those and focus on the hopefully bounded
> steps.) Or maybe add an issue type for blue sky / only half baked
> things?

Sure, feature requests probably account for most of such things.  But 
there could also be bugs that won't be fixed for years.  These should 
remain open, gathering comments.  For example, one might reasonably 
complain that document deletion should not be permitted on an 
IndexReader that's being used for search, since the general contract of 
an IndexReader is that it presents an unchanging view of an index.  In 
practice, this is not a big problem, but it is arguably a bug.  I'd be 
hesitant to resolve it as "Won't Fix", but neither am I going to rush to 
fix it.  So it could remain open until someone both felt it was 
important to fix and has a palatable solution.

> I was thinking about Chris's comments on clarity. I'm still thinking of
> that big "open" bucket. What about a "needs clarification" status? A
> reviewer could bounce "open" back to "needs clarification" analogously
> to "patch available" and "open". There's an "incomplete" resolution
> state but that means (I think) the issue is closed which you'd only want
> to do after the reporter had a chance to clarify. Would that succeed in
> keeping "open" to a reasonable size?

A comment from a committer or contributor should be sufficient to 
explain why something has not been committed, fixed or whatever, and 
what action might next be needed.  The scarcest resource is committers. 
  So we want to be able to focus their activities.  "Patch Available" is 
a call to action.  If something "needs clarification", then the reporter 
of the issue should be able to determine that from the comments and care 
enough to do so.

Put another way, who would be the consumer of the list of all open 
issues that need clarification?  Rather, one should be interested in the 
list of issues that one has submitted which are still "Open", and try to 
minimize that list by contributing patches.

> This, and a couple of Doug's comments, raise the issue of contributor
> vs. committer vs. reviewer vs. other. I'm not clear on how Hadoop does
> this, either mechanistically or by convention. Is reviewer (my term)
> equivalent to contributor or committer?

A reviewer is someone whose opinion influences a committer.  In the end, 
a committer must decide that a patch is ready-to-commit.  If others 
review it positively, especially others who the committer has learned to 
trust, that can influence the committer.  For example, Paul Elschot is a 
contributor (but not committer) whose opinion is typically highly valued.

If things become contentious, then, technically, any change is subject 
to a vote by the project PMC.  But, in practice, committers are trusted 
by the PMC to make changes on their own.  If they are not, they should 
not be committers.

> If no one objects and we have some consensus on how to go forward, I'm
> happy to contribute to implementing it.

What next steps do you propose?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message