Hi all,
Sorry I have not gotten a chance to send this sooner, things here at foss4g have been a bit crazy.
So as many know we have been moving toward pushing out 1.7.0 with the current release candidate at RC3. However there have been a few significant KML changes made since that. Off the top of my head:
* making KML schema compliant
* tweaking the super overlay stuff
As a result I am not very comfortable releasing 1.7.0 without another release candidate. For instance, on 1.7.x there is a bug with the reflector:
http://jira.codehaus.org/browse/GEOS-2258
And in general KML on 1.7.x has suffered from a few regressions. Amr from refractions has reported at least 3 problems with KML on 1.7.x.
Now the real problem is that we have basically zero test coverage for our KML stuff... which is pretty bad imho since we are trying to make a big push on that. And I will be the first to say I am as guilty as everyone else for not writing tests when working on the kml stuff.
So before moving much further with KML improvements we really need to improve our test coverage. We also have the option of rolling back recent changes and apply them after 1.7.0 goes, similar to what David is doing with height templates. I believe Arne is doing this with his patch for kml schema compliance?
Regardless I think we need another release candidate, RC4. And before it goes out I think we need to add a significant number of test cases for KML.
What do people think?
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Regardless I think we need another release candidate, RC4. And before it goes out I think we need to add a significant number of test cases for KML.
What do people think?
I think that we need to get 1.7.0 out pretty soon. I think the GeoSolutions coverage stuff was ready to merge awhile ago, and we told them to wait because we were in feature freeze and 1.7.0 should get out first.
I don't think we should have been tweaking the KML stuff as heavily as we have been, especially with no tests. I don't think we actually need to have all the new KML stuff in for 1.7.0. I've always thought it as 1.7.1 or 1.7.2, putting in more work to make it a lot more solid. I'd say if it's easy to roll back the latest tweaks we might consider that.
So if possible I'd say back out changes, make sure KML works as well as it did for 1.6.x, and get 1.7.0 out asap, so that other features that have been held off can come in. And hopefully after that focus on KML tests and get a 1.7.1 release pretty quick. It'd be good to do quick releases so we continue to get feedback on new features. Like each of these kml improvements, like schema compliance and extrudes, should be quick little point releases with one new feature each. 1.7.0 doesn't need to be perfect, especially not with the new features, it just needs to work as well as 1.6.x
Chris
-Justin
--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.
completely agreed here.
Gabriel
Justin Deoliveira escribió:
Hi all,
Sorry I have not gotten a chance to send this sooner, things here at foss4g have been a bit crazy.
So as many know we have been moving toward pushing out 1.7.0 with the current release candidate at RC3. However there have been a few significant KML changes made since that. Off the top of my head:
* making KML schema compliant
* tweaking the super overlay stuff
As a result I am not very comfortable releasing 1.7.0 without another release candidate. For instance, on 1.7.x there is a bug with the reflector:
http://jira.codehaus.org/browse/GEOS-2258
And in general KML on 1.7.x has suffered from a few regressions. Amr from refractions has reported at least 3 problems with KML on 1.7.x.
Now the real problem is that we have basically zero test coverage for our KML stuff... which is pretty bad imho since we are trying to make a big push on that. And I will be the first to say I am as guilty as everyone else for not writing tests when working on the kml stuff.
So before moving much further with KML improvements we really need to improve our test coverage. We also have the option of rolling back recent changes and apply them after 1.7.0 goes, similar to what David is doing with height templates. I believe Arne is doing this with his patch for kml schema compliance?
Regardless I think we need another release candidate, RC4. And before it goes out I think we need to add a significant number of test cases for KML.
What do people think?
-Justin
So if possible I'd say back out changes, make sure KML works as well as it did for 1.6.x, and get 1.7.0 out asap, so that other features that have been held off can come in. And hopefully after that focus on KML tests and get a 1.7.1 release pretty quick.
I agree here but the trouble is how to determine if it does indeed work as well. Hand testing is good but hardly comprehensive and thorough. So I propose the following:
1. fix the reflector bug which is currently the only known regression
2. roll back all other kml work
3. write a few sanity check tests
4. release 1.7.0-RC4 next week
5. *completely* freeze 1.7.x on anything that is not a bug fix
6. if all goes well release 1.7.0 the following week
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
KML schema compliance was already backed out on Monday. See revision 10324 , http://fisheye.codehaus.org/changelog/geoserver/?cs=10324
-Arne
Quoting Justin Deoliveira <jdeolive@anonymised.com>:
Hi all,
Sorry I have not gotten a chance to send this sooner, things here at
foss4g have been a bit crazy.
So as many know we have been moving toward pushing out 1.7.0 with the
current release candidate at RC3. However there have been a few
significant KML changes made since that. Off the top of my head:
* making KML schema compliant
* tweaking the super overlay stuff
As a result I am not very comfortable releasing 1.7.0 without another
release candidate. For instance, on 1.7.x there is a bug with the reflector:
http://jira.codehaus.org/browse/GEOS-2258
And in general KML on 1.7.x has suffered from a few regressions. Amr
from refractions has reported at least 3 problems with KML on 1.7.x.
Now the real problem is that we have basically zero test coverage for
our KML stuff... which is pretty bad imho since we are trying to make a
big push on that. And I will be the first to say I am as guilty as
everyone else for not writing tests when working on the kml stuff.
So before moving much further with KML improvements we really need to
improve our test coverage. We also have the option of rolling back
recent changes and apply them after 1.7.0 goes, similar to what David is
doing with height templates. I believe Arne is doing this with his patch
for kml schema compliance?
Regardless I think we need another release candidate, RC4. And before it
goes out I think we need to add a significant number of test cases for KML.
What do people think?
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
I double checked after sending the email,
I must have counted wrong going backwards (stopped at r14), because the reordering of styles was still in there.
I've undone it, verified that GeoServer compiles cleanly, xmlint is content with the XML and that (manually) the output looks good. Unfortunately I don't have access to Google Earth.
-Arne
Quoting Justin Deoliveira <jdeolive@anonymised.com>:
Hi all,
Sorry I have not gotten a chance to send this sooner, things here at
foss4g have been a bit crazy.
So as many know we have been moving toward pushing out 1.7.0 with the
current release candidate at RC3. However there have been a few
significant KML changes made since that. Off the top of my head:
* making KML schema compliant
* tweaking the super overlay stuff
As a result I am not very comfortable releasing 1.7.0 without another
release candidate. For instance, on 1.7.x there is a bug with the reflector:
http://jira.codehaus.org/browse/GEOS-2258
And in general KML on 1.7.x has suffered from a few regressions. Amr
from refractions has reported at least 3 problems with KML on 1.7.x.
Now the real problem is that we have basically zero test coverage for
our KML stuff... which is pretty bad imho since we are trying to make a
big push on that. And I will be the first to say I am as guilty as
everyone else for not writing tests when working on the kml stuff.
So before moving much further with KML improvements we really need to
improve our test coverage. We also have the option of rolling back
recent changes and apply them after 1.7.0 goes, similar to what David is
doing with height templates. I believe Arne is doing this with his patch
for kml schema compliance?
Regardless I think we need another release candidate, RC4. And before it
goes out I think we need to add a significant number of test cases for KML.
What do people think?
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.