[hibernate-dev] JIRA notifications

Gunnar Morling gunnar.morling at googlemail.com
Mon Mar 21 15:27:01 EDT 2011


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 at 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 at googlemail.com>
> >
> > > Right, for HV that notification scheme is used and I consider it
> useful,
> > > too.
> > >
> > > Gunnar
> > >
> > >
> > > 2011/3/19 Hardy Ferentschik <hibernate at 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 at 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 at hibernate.org>
> > >> > http://hibernate.org
> > >> > _______________________________________________
> > >> > hibernate-dev mailing list
> > >> > hibernate-dev at lists.jboss.org
> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>
> > >> _______________________________________________
> > >> hibernate-dev mailing list
> > >> hibernate-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> ---
> Steve Ebersole <steve at hibernate.org>
> http://hibernate.org
>



More information about the hibernate-dev mailing list