Hi,
the OSGEO sprint is getting close, I believe we need to push
out an RC1 of GeoServer and of GeoTools too.
Let me elaborate.
GeoServer wise, in Bolsena we'll need to work on a new UI,
and we cannot do that on the current trunk.
I see a few options here:
* make an RC1 and branch off trunk to 1.7.x
* vote an exception to the procedure, and branch without
releasing
* work on the new UI on a separate branch that will
eventually become trunk.
On the gt2 side, we have the SE 1.1 proposal in preparation
that will change a whole lot of files, and potentially
involve various changes in the SLD parsers, producers and
the rendering subsystem in general, making the rendering
subsystem unstable for some time: http://docs.codehaus.org/display/GEOTOOLS/Upgrading+styles
Again, it would be nice to ask GeoTools to branch off
before that change occurs, so that we have time to
absorb the change and leverage the new options that
SE 1.1 offers compared to SLD 1.0. This, by gt2 procedures,
requires the release of an RC1 again.
And we also need the feature speedup patches, either
that, or we work on peformance tuning after RC1 is release.
Thanks for the summary of where we are at. I seem to remember us being able to branch without having a release first... just making sure that a release is coming. Didn't we do this for 1.6.x? Regardless... i think the smoothest path will be to branch before the sprint, be it an exception to procedure or not. Even if we do not get it out before the sprint it will be shortly after.
I also agree with the geotools branch before SE hits trunk. As for when we get the feature speedup back on trunk we could try to do it before the sprint... but I doubt it. It might be something we have to do on branch and port to trunk.
-Justin
Andrea Aime wrote:
Hi,
the OSGEO sprint is getting close, I believe we need to push
out an RC1 of GeoServer and of GeoTools too.
Let me elaborate.
GeoServer wise, in Bolsena we'll need to work on a new UI,
and we cannot do that on the current trunk.
I see a few options here:
* make an RC1 and branch off trunk to 1.7.x
* vote an exception to the procedure, and branch without
releasing
* work on the new UI on a separate branch that will
eventually become trunk.
On the gt2 side, we have the SE 1.1 proposal in preparation
that will change a whole lot of files, and potentially
involve various changes in the SLD parsers, producers and
the rendering subsystem in general, making the rendering
subsystem unstable for some time: http://docs.codehaus.org/display/GEOTOOLS/Upgrading+styles
Again, it would be nice to ask GeoTools to branch off
before that change occurs, so that we have time to
absorb the change and leverage the new options that
SE 1.1 offers compared to SLD 1.0. This, by gt2 procedures,
requires the release of an RC1 again.
And we also need the feature speedup patches, either
that, or we work on peformance tuning after RC1 is release.
Opinions?
Cheers
Andrea
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source. http://sourceforge.net/services/buy/index.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4007,484dac41233922458217002!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
I would hope the code sprint does not involve any work on GeoTools; if possible it would be nice to have the 1.7.x branch and the 2.0.x branch (ie trunk) both work on the same GeoTools. Put another way the lets spend as much time fixing up geotools trunk as we can get away with.
Jody
Hi,
the OSGEO sprint is getting close, I believe we need to push
out an RC1 of GeoServer and of GeoTools too.
Let me elaborate.
GeoServer wise, in Bolsena we'll need to work on a new UI,
and we cannot do that on the current trunk.
I see a few options here:
* make an RC1 and branch off trunk to 1.7.x
* vote an exception to the procedure, and branch without
releasing
* work on the new UI on a separate branch that will
eventually become trunk.
On the gt2 side, we have the SE 1.1 proposal in preparation
that will change a whole lot of files, and potentially
involve various changes in the SLD parsers, producers and
the rendering subsystem in general, making the rendering
subsystem unstable for some time: http://docs.codehaus.org/display/GEOTOOLS/Upgrading+styles
Again, it would be nice to ask GeoTools to branch off
before that change occurs, so that we have time to
absorb the change and leverage the new options that
SE 1.1 offers compared to SLD 1.0. This, by gt2 procedures,
requires the release of an RC1 again.
And we also need the feature speedup patches, either
that, or we work on peformance tuning after RC1 is release.
Opinions?
Cheers
Andrea
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source. http://sourceforge.net/services/buy/index.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
I also agree with the geotools branch before SE hits trunk. As for when we get the feature speedup back on trunk we could try to do it before the sprint... but I doubt it. It might be something we have to do on branch and port to trunk.
Well we can also set our QA bar for GeoTools 2.5.RC1 and ask the SE work to wait. That is what planning and collaboration are about
Jody
