lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: jira workflow
Date Tue, 17 Oct 2006 17:22:04 GMT
: "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?


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

View raw message