[Geoserver-devel] GEOS-3586 Maintenance MO

Hi,

I am trying to get my head around GSIP-22 and 27. I would like to continue
maintaining the module (GEOS-3586). So what would be the ideal way to
commit changes ? In a.b.x branch and then merge them to trunk ? I have
been doing this for both the docus and the source. Once a.b.x is declared
stable and a new one is cut from trunk I will switch to working on a.c.x ?
Nice steps here will be handy.

I am also considering wider worldwind support in Geoserver, particularly
for previewing KML as worldwind KML support matures as well as quickly
checking if terrain/imagery deployed via the DDS/BIL plugin indeed worked.
Also for pure 3D jazz to counter-balance the Javascript goodness of
openlayers. This will be via the proposal here ->
http://geoserver.org/display/GEOS/WorldWind+Integration. I am available to
mentor for GSoC and I will canvass for some students.

Cheers,

Tisham.

Hi Tisham,

For community modules the commit policies are pretty lax and really up to the community module maintainer. I guess my personal preference is to do primary development work on the trunk and then backport to the stable branch. I find this works best in cases where there are some experimental changes i don’t want to backport to stable, but some bug fixes that i do. However that is less of a concern in a community module since they are sort of by definition experimental. That model applies more once the module becomes an extension or a core module since by definition there is an expectation that those modules be stable on the stable branch.

Hope that helps.

-Justin

On Fri, Mar 4, 2011 at 7:42 AM, <tisham@anonymised.com> wrote:

Hi,

I am trying to get my head around GSIP-22 and 27. I would like to continue
maintaining the module (GEOS-3586). So what would be the ideal way to
commit changes ? In a.b.x branch and then merge them to trunk ? I have
been doing this for both the docus and the source. Once a.b.x is declared
stable and a new one is cut from trunk I will switch to working on a.c.x ?
Nice steps here will be handy.

I am also considering wider worldwind support in Geoserver, particularly
for previewing KML as worldwind KML support matures as well as quickly
checking if terrain/imagery deployed via the DDS/BIL plugin indeed worked.
Also for pure 3D jazz to counter-balance the Javascript goodness of
openlayers. This will be via the proposal here →
http://geoserver.org/display/GEOS/WorldWind+Integration. I am available to
mentor for GSoC and I will canvass for some students.

Cheers,

Tisham.


What You Don’t Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.