> In short, imho, the process as-is can be carried on only by a core > developer, for the simple reason that running cite tests can > uncover issues, and those in turn can be fixed only by > someone that knows GS/GT well.
+a lot. As someone who wore the Release Manager hat a few times, this was essentially my experience. The CITE tests as part of the release process was the most inefficient part, since I could do nothing about any test failures, so I had to play whisper-down-the-lane with the core devs. This back and forth could stretch out interminably. Automating CITE tests would make it much easier to push the rock over the hill. I might even want to volunteer to release again! Thanks, Mike Pumphrey OpenGeo - http://opengeo.org On 5/14/2010 3:31 AM, Andrea Aime wrote: > Hi, > looking someone struggingling for the n-th time trying to > make a release makes me really wonder about the viability > of the current release process. > > In short, imho, the process as-is can be carried on only by a core > developer, for the simple reason that running cite tests can > uncover issues, and those in turn can be fixed only by > someone that knows GS/GT well. > > And oh, provided you manage to put togheter the necessary black > magic to make the cite tests to work. > I consider making GS releases a sort of art (and a test of anyone > patience). > > Having CITE tests out of the release process would be a great > step in simplifying the process. > To do that we have to either give up the confirmation that we're > still CITE compliant, or we have to consider CITE as a daily > activity, something that runs automatically just as our normal > build. > > Do you think it's possible to fully automate the process? > The bits needed are: > a) setting up databases: check, it's something that can be done, > give the build process a configuration of where the db is > and a script that can clean up and rebuild the db and > we're in business > b) starting up and shutting down GeoServer: check, the Start > utility class could be used as a starting point for something > that starts a GeoServer with a specific configuration, > and eventually shuts it down > c) starting up the CITE tests with a specific configuration: > uh, dunno... maybe? This is where I see various issues. > > Issues with teamengine: > - to run as part of a maven build we'd need to package up > and put on repositories the engine and the test suite. > This is redistribution. Is that something we can do? > If we cannot, I guess we can still resort to some form > of private sharing, marking those jars as "provided" > and giving to a selected number of people the files along > with the instructions to install them in their maven > repositories. > - the teamengine already has command line utilities to start > a specific test suite, but I see no way to specify the > parameters, which are usually asked for in an interactive window. > I see no easy way to state the test parameters manually. > This looks like a roadblock > - Once the suite is run we need to collect the results and > declare victory or failure. > It's something that can be done by looking into the > logs, and seems a bit painful, but doable > > If we can go past the above issues I believe we could > roll a set of maven modules, each designed to have > a specific set of dependencies (think about the need > to exclude WCS 1.1 in WCS 1.0 tests), each performing > a custom setup (db, files, whatever) and running > a specific test suite. > Basically a module to be built for each of the > CITE tests that we want to run. > > And then imagine Hudson running that every single night. > Imagine also that you get a report of failures, and you > can run one of the above builds specifying the exact > test you want to re-run for debug purposes. > > May not seem much, but to me, compared to what we have > today, feels like Nirvana. > > Cheers > Andrea > > > ------------------------------------------------------------------------------ _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
