On 04/27/2015 09:16 AM, Jacques Le Roux wrote:
Thanks Adam for the very detailed workflow... answers inline, mostly
about vocabulary :) ...
Le 23/04/2015 07:56, Jacopo Cappellato a écrit :
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.
There is also the important "Patch available" status...
With git, there is never a single patch. It's a commit stream, a
branch, a repo fork. But yeah, I'll think about using this status.
5: Commits are done to the shared branch from (2), with each message
tagged with the id(s) from (3).
Cool to put the name of the possible contributor too ;)
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.
A commit is not pushed it's committed :p.
Ok, not pushed, not committed. How about, "when the change leaves the
developer's system, and is somehow made available in the shared
branch?" This could be via a commit to a shared repo(ala svn), or a
pull request(ala git/fork)?
In don't agree about the "the change is not available for testing by
the reported yet." S/He can always checkout a branch. Anyway I agree
not being "available to the rest of the ecosystem" is a status blocker.
The integration area(svn branch, git repo fork) may not be available for
the original reporter to easily test. There would need to be a download
area for the resultant binaries, or the user would have to check out
directly. Not all end-users can or want to compile ofbiz.
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 ????
"Some code reviewer" here must be a committer to be able to merge and
commit the branch, and it's not in "trunk/master/release", it's, so
far, eventually in svn trunk HEAD.
For the rest I agree with you and Jacopo
Jacques
Let's not tie the workflow to svn-only terms. Just because ofbiz
primary is currently managed through svn, outside vendors might be using
git, and can use more advanced push/pull/merge-request type workflows.
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
