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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Nutch-developers mailing list Nutch-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nutch-developers
