jira workflow

[Adam Heath <do...@brainfood.com>]

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.

Re: jira workflow

[Adam Heath <do...@brainfood.com>]

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 <do...@brainfood.com> 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
>>
>>
>>

Re: jira workflow

[Jacques Le Roux <ja...@les7arts.com>]

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 <do...@brainfood.com> 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...

>>
>> 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.
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.
>> 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

>>
>> 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
>
>
>

Re: jira workflow

[Jacopo Cappellato <ja...@hotwaxsystems.com>]

On Apr 22, 2015, at 10:07 PM, Adam Heath <do...@brainfood.com> 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

Re: jira workflow

[Pierre Smits <pi...@gmail.com>]

Adam,

JIRA offers quite some flexibility with respect to defining status field
values (see:
https://confluence.atlassian.com/display/JIRA063/Defining+Status+Field+Values)
and workflow schemes (
https://confluence.atlassian.com/display/JIRA063/Configuring+workflow+schemes
)

It might be so that what we have got is limited, e.g. just the default re
status field (values
https://confluence.atlassian.com/display/JIRA063/What+is+an+Issue#WhatisanIssue-Status
)

I remember Jacques and I having discussed potential changes (status and
workflow) in the past and what the process would of having that
implemented. If I remember well, there are some options available to
projects. But such questions about extensions should best be directed at
INFRA.

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Wed, Apr 22, 2015 at 10:07 PM, Adam Heath <do...@brainfood.com> 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.
>
>