On Apr 22, 2015, at 10:07 PM, Adam Heath <[email protected]> wrote:
> So, I've started attempting to use JIRA and branches, to implement a new > workflow. Basically, I'm seeing what the capabilities of the systems are. > I've run into a bit of a mis-feature, I believe, so I'm asking here to see if > anyone might help. > > Here is the workflow I am attempting to follow. > > 1: Bug/feature/etc gets created. > > 2: Branch is made with the name set to the id from (1). > > 3: Sub-tasks are made, to split up the large amount of work from (1). > > 4: Each sub-task can be assigned to different people, and work proceeds in > parallel. The state of the sub-task moves from OPEN to IN-PROGRESS. > > 5: Commits are done to the shared branch from (2), with each message tagged > with the id(s) from (3). > > 6: When a commit from (5) is pushed, the developer doing the work moves the > issue state to RESOLVED. This is not closed, as the change is not available > for testing by the reported yet. Nor has it been made available to the rest > of the ecosystem. > > 7: Some code reviewer looks at the series of commits, and if they do what > they set out to do, merges the branch to trunk/master/release. The issue > state(s) change from RESOLVED to ???? > > 8: The original filer looks at trunk/master/release, and if the original > report has been resolved, changes the issue state from ???? to CLOSED. > > I don't see an option in JIRA for the represenative state in 7. The commits > I have just sent into branch OFBIZ-6275 are currently at line (6) from above. > Thanks for the detailed workflow, this is a good topic. For now, without adding statuses or customizing the workflow (we may have to contact the ASF Infra for this), I would suggest to use ???? = CLOSED. This means that the task will be closed in step 7 when the feature branch is merged into the trunk/master/release branches. At step 8 the original reported will either add a comment confirming that the issue is resolved or reopen the task. Jacopo
