Doug
Can you answer the question of how to add developer names to JIRA or if
that is only for committers?
Dennis
Doug Cutting wrote:
Andrzej Bialecki wrote:
The workflow is different - I'm not sure about the details, perhaps
Doug can correct me if I'm wrong ... and yes, it uses JIRA extensively.
1. An issue is created
2. patches are added, removed commented, etc...
3. finally, a candidate patch is selected, and the issue is marked
"Patch available".
"Patch Available" is code for "the contributor now believes this is
ready to commit". Once a patch is in this state, a committer reviews it
and either commits it or rejects it, changing the state of the issue
back to "Open". The set of issues in "Patch Available" thus forms a
work queue for committers. We try not to let a patch sit in this state
for more than a few days.
4. An automated process applies the patch to a temporary copy, and
checks whether it compiles and passes junit tests.
This is currently hosted by Yahoo!, run by Nigel Daley, but it wouldn't
be hard to run this for Nutch on lucene.zones.apache.org, and I think
Nigel would probably gladly share his scripts. This step saves
committers time: if a patch doesn't pass unit tests, or has javadoc
warnings, etc. this can be identified automatically.
5. A list of patches in this state is available, and committers may
pick from this list and apply them.
6. An explicit link is made between the issue and the change set
committed to svn (Is this automated?)
Jira does this based on commit messages. Any bug ids mentioned in a
commit message create links from that bug to the revision in subversion.
Hadoop commits messages usually start with the bug id, e.g.,
"HADOOP-1234. Remove a deadlock in the oscillation overthruster."
7. The issue is marked as "Resolved", but not closed. I believe issues
are closed only when a release is made, because issues in state
"resolved" make up the Changelog. I believe this is also automated.
Jira will put resolved issues into the release notes regardless of
whether they're closed. The reason we close issues on release is to
keep folks from re-opening them. We want the release notes to be the
list of changes in a release, so we don't want folks re-opening issues
and having new commits made against them, since then the changes related
to the issue will span multiple releases. If an issue is closed but
there's still a problem, a new issue should be created linking to the
prior issue, so that the new issue can be scheduled and tracked without
modifying what should be a read-only release.
Doug
