lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Parkes" <>
Subject RE: jira workflow
Date Tue, 17 Oct 2006 19:23:53 GMT
Looking at some currently closed issues, it looks like it should be
possible to add comments and links to closed issues. It provides the
comment button anyway. I haven't tried to push it. We could test on the
test SOLR issue.

Looking at the Jira docs, it looks like you can configure closed issues
to be editable or not, your choice. Other than the edit operation, it
doesn't look like you can configure the set of available operations on a
per-status (state) basis. (Again, that's from looking at the docs, so I
could have missed something.)

As to the issue of "rough patches", I guess I'm thinking about bounded
lists vs. unbounded lists. As mentioned, it would be nice if the number
of issues in "patch available" (the polished kind) was kept small. I
think on Derby, they mail that list of issues to the dev list
periodically (attention by annoyance).

To keep other states from growing without bound, we would either have to
have a state which was meant to be that way (for those
hair-brain-stormed kinda of patch), or age them out after a while, maybe
closing them for lack of interest.

My main concern is that things get lost in lists that grow without

With the Hadoop workflow, it's not really an issue for things with
patches and active contributors. 

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

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?

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?

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

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

View raw message