James Strachan wrote:
Just an idle observation as I'd never seen this workflow before on
JIRA so thought I'd ask :)

I'm new to JIRA as well...

I've been watching some of the recent JIRA activity with interest.
I've seen a few JIRAs arrive, someone submits a test case who's not a
committer, then the issue gets assigned to the person who submitted
the patch. In some cases; when there may be many patches to assign
over time, I can understand it (e.g. ZOOKEEPER-78 could take a zillion
iterations before the feature is complete) - but in general if one
JIRA gets one patch from a non-committer, should the JIRA be left
unassigned - or assigned to a committer to review and apply or
reject-with-reason the patch?

I believe the workflow is that the jira is assigned to the person resolving the issue (ie submiting the patch). You/Hiram have been added as "contributors" to jira, this means that jiras can be assigned to you. We typically add ppl to the contributor list as soon as they submit a patch.

After that point you do the back/forth in the comments trying to get everyone to agree to a resolution. If this is a patch you then change the status to "patch available" and ask for review/voting, after which if you get a "+1" it's then up to a committer to commit to svn.

full details here:

i.e. lets say I raise a JIRA and attach a patch; once we're at that
stage I can't actually do anything else, not being a committer - other
than add another version of the patch :) So am not sure if its worth
assigning the issue to me. I guess the person who raised the issue &
submitted the patch can always mark it as unassigned :)

It's assigned to the person who resolved the issue. If accepted it's up the the committers to get it into svn, but you (the resolver) are still responsible. This information is also important for reporting purposes.

No biggie I just thought I'd ask if this was an intentional way you
guys had worked together in the past?

This is generally how Hadoop core/hbase do things.


Reply via email to