On Wed, May 16, 2012 at 1:48 AM, Jody Garnett <jody.garn...@gmail.com>wrote:
> To do so it uses the jira rest api (which is nice btw). This is something
> I would like feedback on.
>
> Bleck - tough call.
>
> We have a couple of options here on what to do with respect to jira.
>
> 1. don't do any checks against jira, and leave that a manual process
>
> In my experience going through the Jira list is educational; for two
> reasons:
> - as often I find items that are marked "resolved" but not yet closed as
> they are waiting confirmation.
> - often issues are fixed (usually due to issues being duplicated etc…)
>
> This is also our "last chance" to see what is going on before the issues
> are punted over to the next release.
>
> 2. halt the build if the release is not released in jira or there are
> unresolved issues, making releasing on a jira manually a precursor to
> running the script
>
>
>
> 3. mark the release as released in jira, and push back any unresolved
> issues to the next version
>
> I would go with this option (despite the temptation to halt the build for
> manual review).
>
> Reason is:
> a) we are shooting for a two hour release window
> b) we can update the release notes in Jira after the fact; and the page
> will update
>
> More options welcome.
>
> Can we promote any "resolved' issues to "closed" if they have now been
> included in a release?
>
I don't see why not... I believe resolved is meant to signify it has been
fixed by a developer and closed is used more as a confirmation that the fix
actually works. We don't really use the latter so i am ok with just marking
stuff with closed when we release. Like to hear what others thing about
this before proceeding though.
>
> Jody
>
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
