+1 for adopting the same types of process with Nutch. 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 > >
------------------------------------------------------------------------- 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
