Yeah I think a new hudson job on the build server could do all of this and
automate pretty everything minus the announcements. Basically the input
would simply be a release number and a revision. The job would tag, build,
update version numbers, etc... It is definitely a fair bit of scripting work
but certainly doable.
Which brings me to a related point, i would like to commit all the hudson
scripts into svn... there is a lot of logic there and currently it is just
sittin gon the build server unversioned.
On Fri, Sep 30, 2011 at 6:47 AM, Jody Garnett <[email protected]>wrote:
> The current situation, with the cite tests running every night, is
> certainly better
> than it was once, but there is still a lot of work to do, and that work has
> to
> be done by someone that has all the keys to the project administration
> areas.
>
> In a perfect world the maven release target would work and take care of
> tagging etc. We could then place that in hudson and ask someone to poke the
> button (and make the JIRA release notes).
>
> Sometimes I'd like to delegate the release to some of my colleages at
> work that might have a few spare hours, but they don't even have commit
> access so that is not feasible.
>
> See above; as long as hudson has commit access it would work. But they
> would need to sign up to seven Xircles of haus in order to kick out the Jira
> release notes.
>
> Any suggestions on what we could do to improve the release process?
>
> I am a big fan of trying the collaborate; and have a standing offer open to
> release GeoTools if someone needs to make a GeoServer or uDig release.
>
> That does not however make good use of your colleagues. In a sense when the
> release process was in terrible shape it was easier to make use of
> volunteers for testing and QA.
>
> The ideal-ideal situation would be something like a customized hudson build
> that given the release notes and the branch name does it all, making the
> packages
> available for upload to sourceforge and the like.
> But any way to further shrink the release times would be welcomed
>
> We could write a shell script for some stages of the release process (the
> staging of files to be zipped up and uploaded to source forge for example).
> We have done something similar for uDig now and it makes an amazing
> difference in how easy it is to make a release.
>
> If we were really worried about cross platform we could make it an ant
> script.
>
> Jody
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
