This is a good idea IMHO - particularly if the process of tagging and assigning release identifiers can be automated - automation requires clarity of the process, which is a good thing too :-)
Andrea's experience about whats actually most reliable is really important to learn from. Two suggestions/comments: 1) You might use something like a doodle poll to set a release date (say with a two week window?) - then anyone who some stuff in the pipeline who wants a couple of days grace can vote - if you get no negative votes on the doodle, schedule an automated release on the earliest date 2) Having to configure specially for CITE tests is a nasty nasty thing - sure there is data involved we dont want to distribute, but its an anathema for interoperability to use magic to pass conformance tests. Automating running them sure is a huge improvement though. I wonder how much app-schema support would buy us being able to pass CITE tests out-of-the-box? Is there a jira task or wiki page which specifies all the impacts of the CITE specific config so we could review each of these and plan a cleaner solution? Rob On Tue, Nov 9, 2010 at 2:10 AM, Justin Deoliveira <jdeol...@opengeo.org> wrote: > This is sure to be an interesting thread. Here are some of my thoughts. > I totally agree that we need a much more agile and lightweight release > process. And I think much could be done in support of this starting with the > build server. As Andrea suggests we should be producing artifacts that > contain svn revision information. This has been something on my todo list > for some time regardless. > My only worry about such a release process would be that currently our > commit policies allow us to commit changes quite liberally to the stable > branch. If we are going to be releasing more often I would like to see that > policy more strict and kept to bug fixes only. Currently we do have a very > long release cycle but at least it gives developers and users who try > nightly builds to flush out regressions that are introduced. However on the > other hand a lighter weight process allows us to push out release much more > quickly, so if we do ship a regression at least it will be easy to release a > new release > At the end of the day GeoServer is tied to Geotools. And currently the > restriction of having to put a geotools release for every geoserver really > ties our hands. If releasing geotools takes a day there is only so much we > can do. We could consider dropping the requirement of having to ship with an > official geotools release. However I sympathize with Jody in that this would > mean less (if any) geotools releases. > In the end I think the best way forward would be to try to also make the > geotools release process better as well. If releasing geotools were easier > we could drop the requirement of having an official geotools release, and > still produce regular geotools releases. > I think much could be done on the build server to make the release process > for both projects nicer. Basically a new job that you fire off, enter in svn > revision information, tag name, etc... and all the release artifacts get > spit out automagically. That coupled with adding svn revision to nightly > builds I think will go a long way. > 2c. > -Justin > On Sun, Nov 7, 2010 at 1:48 AM, Andrea Aime <andrea.a...@geo-solutions.it> > wrote: >> >> On Sat, Nov 6, 2010 at 11:34 PM, Jody Garnett <jody.garn...@gmail.com> >> wrote: >> > That sounds sensible to me; the only glitch I see is perhaps due to a >> > separate goal. I would like to see geotools released occasionally; and we >> > have had the policy of only releasing geotools when geoserver passes cite >> > tests. The only time for that to happen has been when geoserver has been >> > released ... >> > >> > It sounds like we could do that more often after Justin's QA work. >> >> In fact there is nothing stopping you from releasing geotools wherever you >> want. >> >> > So if we released geotools; deployed; and cut trunk over to the correct >> > version of GeoTools for a day or so we could still get a nightly built with >> > non snapshot copy of geotools? And then proceed with the rest of your plan. >> >> Right, we cannot exactly take the artifacts built during the night because >> they >> contain SNAPSHOT in the version number. >> Wondering if it would be possible to make a Hudson "release" build that >> takes >> the svn revision of geotools, the target revision, and automates it all >> (tag, rename, commit, package, deploy). >> And something similar for GeoServer as well. >> >> > >> > So what does that look like... >> > 1. call a code freeze >> >> I would not even want to go there. If we know that revision N of GeoTools >> passed >> all the tests and was good for GeoServer CITE tests we just have to tag >> it and release it. >> Calling out before the release should still be done to ensure there is no >> big >> work in progress, but on a quiet branch such as 2.6.x and 2.0.x I would >> not >> see the problem in taking a arbitrary revision number that passed all the >> tests and calling it the release. >> >> > 2. release geotools and switch geoserver over to it >> > 3. force a nightly release and run of cite tests (or wait till the next >> > day) >> > 4. tag geoserver and release (installers etc...) >> > 5. call off the code freeze >> >> I think this would not work. We cannot have an extensive freeze, but I >> know >> I may have 2 spare hours one day to make a release and then be chock full >> of other work for two weeks. >> I'd like a release process that can work within these short and >> unpredictable >> windows of spare time. As we have seen in the last months asking for a >> more >> controlled and predictable release management simply does not work, >> we don't have the time for it. >> >> Cheers >> Andrea >> >> ----------------------------------------------------- >> Ing. Andrea Aime >> Senior Software Engineer >> >> GeoSolutions S.A.S. >> Via Poggio alle Viti 1187 >> 55054 Massarosa (LU) >> Italy >> >> phone: +39 0584962313 >> fax: +39 0584962313 >> >> http://www.geo-solutions.it >> http://geo-solutions.blogspot.com/ >> http://www.linkedin.com/in/andreaaime >> http://twitter.com/geowolf >> >> ----------------------------------------------------- >> >> >> ------------------------------------------------------------------------------ >> The Next 800 Companies to Lead America's Growth: New Video Whitepaper >> David G. Thomson, author of the best-selling book "Blueprint to a >> Billion" shares his insights and actions to help propel your >> business during the next growth cycle. Listen Now! >> http://p.sf.net/sfu/SAP-dev2dev >> _______________________________________________ >> Geoserver-devel mailing list >> Geoserver-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > > ------------------------------------------------------------------------------ > The Next 800 Companies to Lead America's Growth: New Video Whitepaper > David G. Thomson, author of the best-selling book "Blueprint to a > Billion" shares his insights and actions to help propel your > business during the next growth cycle. Listen Now! > http://p.sf.net/sfu/SAP-dev2dev > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
