: "patch submitted" which, as it's used on Hadoop, seems to facilitate : communication. State changes (open->patch submitted, : patch-submitted->open) seem to help communications between contributors : and reviewers. Looking at the Lucene Java Jira, sometimes "[patch]" is : put at the beginning of the description of the issue to indicate : something similar, but this isn't used too consistently and doesn't seem : to be as effective. It also requires custom filters to easily see all : issues in the "patch submitted" state.
FYI: the use of "[PATCH] in the description seems to largely be a holdover from bugzilla as a poor mans mechanism of tagging issues. it pretty much lost it's utility when the migration to Jira happened, since the general public can't edit issue titles. : There are a couple of issues around the Hadoop workflow I'm aware of. : One is that once an issue is closed, it can't be reopened. As I : understand it, this is because on Hadoop, they use the Jira feature : which allows automated generation of release notes. As someone who is As i understand it, this is orthoginal to the question of adding more "statuses" that issues can exist in, and it might be better to evaluate the ideas seperately. Personally: I think as long as comments and "links" can be added to issues even after they are closed, there is really no downside to preventing closed issues from being re-opened. : The other thing I was thinking of was the case where we say "if you're : working on something, go ahead and submit a patch even if it's not : polished or you aren't sure you want it to be a candidate for the trunk. : Let others look at it." I think that's clearly a good thing to have, but : I wonder what the best way to handle it in Jira is. What state should be : used? Perhaps we should have two new statuses: "rough patch available" and "polished patch available" ? The other thing i would like to see tracked better is the distinction between issues that unit tests attached and issues that do not ... this is somewhat orthoginal to patch availablity ... sometimes people submit patches containing new functionality without writing unit tests for it, othertimes people identify bugs and suply tests deomonstrating the bug without being able to suggest a patch to fix the problem -- both of these cases should be distinguishable from what i would consider as "vauge" bug reports or feature requests that describe a problem (or feature) without any concrete demonstration of the issue. As i understand it, Jira issue statuses are "linear" so a status for "unit test available" wouldn't really work (since it could happen before or after a patch is available) ... is there a more general "tagging" or "flagging" mechanism in Jira? -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
