Hi,
the workflow looks like this:
* A new issue is created -> the issue is in state "open"
* Work begins -> perform workflow action "start progress" -> issue is in
state "coding in progress"
* Work is done -> perform workflow action "attach pull request" (enter the
number of the pull request) -> issue is in state "pull request sent"
* Pull request is applied on GitHub -> perform workflow action "pull request
closed" (chose resolution, e.g. done) -> issue in state "resolved"
* Double-check everything, perform action "close issue" -> issue is in state
"closed"
The screenshots in Dan's mail give quite a good impression of how it works.
Currently I add a comment with an issue's pull request, so I think this
would be quite useful.
Gunnar
2011/3/19 Steve Ebersole <steve(a)hibernate.org>
So what are the states involved in the custom workflow?
Transitions?
On Saturday, March 19, 2011, at 09:30 am, Gunnar Morling wrote:
> Hi,
>
> while talking about JIRA configuration another thing came into my mind,
> which relates to the issue workflow.
>
> For Seam's JIRA Dan set up an enhanced workflow, which provides a closer
> integration with GitHub pull requests. For one there is a dedicated issue
> field "pull request", but also the issue lifecycle is linked to pull
> requests with a new issue state "pull request sent".
>
> IMO that's pretty useful as it improves visibility of the issue/pull
> request relationship and reduces chances, that pull requests get lost.
> More information can be found in this mail:
>
>
http://seam-framework.2283336.n4.nabble.com/git-pull-request-JIRA-workflow-
> td3272708.html
>
> In case there should be interest in using that workflow for Hibernate's
> JIRA I think Dan would happily provide more information how this was set
> up.
>
> Gunnar
>
>
>
> More information
>
> 2011/3/19 Gunnar Morling <gunnar.morling(a)googlemail.com>
>
> > Right, for HV that notification scheme is used and I consider it
useful,
> > too.
> >
> > Gunnar
> >
> >
> > 2011/3/19 Hardy Ferentschik <hibernate(a)ferentschik.de>
> >
> >> I think it makes sense for all projects. I think Validator and Search
> >> are using it already.
> >> I not they should at least in my opinion.
> >>
> >> --Hardy
> >>
> >> On Fri, 18 Mar 2011 19:13:01 +0100, Steve Ebersole <
steve(a)hibernate.org>
> >>
> >> wrote:
> >> > I will be changing Hibernate Core JIRA project to use the
> >> > participant-based
> >> > notification scheme. Should I change over any other projects while
I
> >> > am in
> >> > there?
> >> >
> >> > What is participant-based notification? Basically, any participant
> >> > (reporter,
> >> > assignee and all commenters) is automatically notified on changes.
> >> >
> >> > ---
> >> > Steve Ebersole <steve(a)hibernate.org>
> >> >
http://hibernate.org
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev(a)lists.jboss.org
> >> >
https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev(a)lists.jboss.org
> >>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org