On Wed, May 16, 2012 at 1:53 AM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> On Wed, May 16, 2012 at 7:55 AM, Justin Deoliveira <jdeol...@opengeo.org>
> wrote:
> > The end result is all the artifacts wind up in a single directory
> matching
> > the release name. For example:
> >
> > http://gridlock.opengeo.org/geoserver/release/2.2-beta2/
>
> Looking good :-)
>
> > The above list of tasks is an overview, the main release script actually
> > does a bit more which is what i would like to discuss. The script also
> > checks jira and determines two things:
> >
> > 1. is the release actually released on jira
> > 2. does the release have any open/unresolved issues filed against it
> >
> > To do so it uses the jira rest api (which is nice btw). This is
> something I
> > would like feedback on. 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
> > 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
>
> Hum... I don't remember ever doing a release where all the tickets
> assigned to
> it were resolved.
> I'd go for 3, the release is not happening by itself anyways, and hopefully
> there will be a bit of discussion on the ml before someone pushes the
> "big red release button".
>
To clarify i wasn't implying that we fix all issues assigned to the version
being released, just move them. The moving being manual or automatic.
Sounds like people like the automatic approach so will push on with that.
>
> > The second thing I would like to discuss is how we handle the README.
> > Currently when we release we update the README on the main branch (and
> not
> > the tag). I would kind of like to avoid committing anything to the main
> > branch in an automated process. For example what happens if we run the
> > release, it fails and we run it again. We have to check if the readme has
> > been already updated, etc... While certainly possible with some script
> mojo
> > it seems like an error prone process I would like to avoid.
> >
> > So what I would like to propose is the following. We don't ever update
> the
> > README on the main release branch. We leave it generic with information
> > about the project, where to find the docs, etc... On the tag we create we
> > would generate a new file called "RELEASE_NOTES.txt" (or something to
> that
> > effect) that contains the stuff we usually put in the README like
> revision
> > info and the new and noteworthy info for that release. To generate the
> new
> > and noteworthy for the release notes i was thinking we could come up
> with a
> > heuristic. One such heuristic could be to pull out any new feature or
> > improvement, and perhaps any issue that is a high priority one. Anyways,
> you
> > get the idea. And naturally it would contain the link to the entire
> > changelog from jira like we do now. Perhaps we should just stick to
> simple
> > and put the revision info and the changelog link in the release notes.
> > Probably what I will do for a first pass if people are into the idea.
>
> Hum... this file is going to be inside the packages and on sourceforge, but
> wondering how many people are actually going to read it?
> A link to the release notes on Jira seems reasonable to me.
>
Cool. I think the same... it would be interesting to know how many people
actually do read that file.
>
> Alternatively we allow the releaser to compose a narrative that is going to
> be included in the README file, possibly the same message that is then
> going to be sent to the mailing lists and reused in the blogs.
>
Yeah, i thought about this as well. I will look into some of the options
here. Good point about using it for the notifications as well.
>
> > Those are the two main things I need input on thus far. Aside from the
> above
> > stuff the main thing left to do is to do the upload to sourceforge. I
> think
> > this will be pretty straight forward. The idea is that there would be a
> > second release job (called geoserver-release-publish or something) that
> > would take the release tag as input and basically just upload all the
> > artifacts from the distribution directory to sourceforge. The idea is
> that
> > after the main release job (and the hudson installer jobs) complete the
> > person doing the release would do a quick sanity check on the artifacts,
> fix
> > issues, etc... Once completed the release publish job would do the final
> > push.
>
> Yep, sounds good to me.
>
> > Oh, and another TODO will be to take the associated geotools info
> (version,
> > revision, etc...) and ensure that is what is included in the geoserver
> > build. I guess same goes for geowebcache as well.
>
> Yep
>
> > That is it for now. Looking forward to hearing feedback.
>
> Nothing in particular. Kudos to your bash-fu and pretty excited about this
> new work becoming real :)
>
> Cheers
> Andrea
>
> --
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax: +39 0584 962313
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
--
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
