[Geoserver-devel] GSIP 22: Extensions, review + vote

Hi all,

While we are cleaning up GSIP's, this one is pretty much ready to go. Could PSC members please review and vote or provide some feedback.

Thanks,

-Justin

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

See earlier review of all the GSIP's there is some overlap between these two:
- http://geoserver.org/display/GEOS/GSIP+17+-+Community+module+handling
- http://geoserver.org/display/GEOS/GSIP+22+-+Extensions

Can this be resolved; or combined into a single policy change separating out the difference between how these are handled?
The GSIP+22 will need to change or define project build procedure; we should figure out what documentation pages
need to be updated?
- Can we have a procedure for "removing an extension"
- Since these are a lot more formal than community modules; can we get a wiki page with docs? Or even a formal installation/useage doc?

I am correct in thinking these are full fledged running modules (like WPS?) that are ready to go - they are just not in the default GeoServer download. As such I would like to hold them to the same high standard.

Jody

Justin Deoliveira wrote:

Hi all,

While we are cleaning up GSIP's, this one is pretty much ready to go. Could PSC members please review and vote or provide some feedback.

Thanks,

-Justin

Hi Justin,

we already discussed a bit on this issue in a previous email, and you
have clarified my concerns ... so basically is +1 for me, but I agree
with Jody too, a doc and/or a formal installation useage doc would be
great to add along with an extension.

On Fri, Jul 18, 2008 at 12:33 AM, Jody Garnett <jgarnett@anonymised.com> wrote:

See earlier review of all the GSIP's there is some overlap between these
two:
- http://geoserver.org/display/GEOS/GSIP+17+-+Community+module+handling
- http://geoserver.org/display/GEOS/GSIP+22+-+Extensions

Can this be resolved; or combined into a single policy change separating
out the difference between how these are handled?
The GSIP+22 will need to change or define project build procedure; we
should figure out what documentation pages
need to be updated?
- Can we have a procedure for "removing an extension"
- Since these are a lot more formal than community modules; can we get a
wiki page with docs? Or even a formal installation/useage doc?

I am correct in thinking these are full fledged running modules (like
WPS?) that are ready to go - they are just not in the default GeoServer
download. As such I would like to hold them to the same high standard.

Jody

Justin Deoliveira wrote:

Hi all,

While we are cleaning up GSIP's, this one is pretty much ready to go.
Could PSC members please review and vote or provide some feedback.

Thanks,

-Justin

-------------------------------------------------------------------------
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

--
-------------------------------------------------------
Eng. Alessio Fabiani
Vice-President /CTO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 349 8227000

http://www.geo-solutions.it

-------------------------------------------------------

Jody Garnett ha scritto:

See earlier review of all the GSIP's there is some overlap between these two:
- http://geoserver.org/display/GEOS/GSIP+17+-+Community+module+handling
- http://geoserver.org/display/GEOS/GSIP+22+-+Extensions

Can this be resolved; or combined into a single policy change separating out the difference between how these are handled?
The GSIP+22 will need to change or define project build procedure; we should figure out what documentation pages
need to be updated?

+1

- Can we have a procedure for "removing an extension"

I would suggest the following. The module goes back into community
limbo if any of the requirements for getting into extension drops
below the acceptable level. When anyone notices the requirements
are no more there, the PSC contact the maintainer, which has to fix up the problem in time for the next release. If that does not happen,
the module gets moved into community

- Since these are a lot more formal than community modules; can we get a wiki page with docs? Or even a formal installation/useage doc?

Agreed, this should be a requirement to get into "extensions".

I am correct in thinking these are full fledged running modules (like WPS?) that are ready to go - they are just not in the default GeoServer download. As such I would like to hold them to the same high standard.

Yep.
Cheers
Andrea

Hi Justin; the WPS team went to try and use this proposal but it is not ready yet :frowning:

We tried talking about it in todays IRC meeting and got stalled out on the issue of having a maintainer.

The balance here is one of resources:
- on one side donating code to GeoServer cannot be a sentence to provide a staff member on call forever
- on the other side donating code to GeoServer does not mean the community will maintain the code for free

Andrea and I eventually worked out the compromise of either having a maintainer; or letting the PSC act like one (including kicking the module back to community status if needed). We both want to learn from the GeoTools experience of shapefile patches piling up in Jira.

It sounds like it too late for this procedure to be followed by the WPS team for this phase of the project. It would be very good if this procedure could be worked out prior to negotiating for continued work.

Cheers,
Jody

Jody Garnett wrote:

See earlier review of all the GSIP's there is some overlap between these two:
- http://geoserver.org/display/GEOS/GSIP+17+-+Community+module+handling
- http://geoserver.org/display/GEOS/GSIP+22+-+Extensions

Can this be resolved; or combined into a single policy change separating out the difference between how these are handled?
The GSIP+22 will need to change or define project build procedure; we should figure out what documentation pages
need to be updated?
- Can we have a procedure for "removing an extension"
- Since these are a lot more formal than community modules; can we get a wiki page with docs? Or even a formal installation/useage doc?

I am correct in thinking these are full fledged running modules (like WPS?) that are ready to go - they are just not in the default GeoServer download. As such I would like to hold them to the same high standard.

Jody
  

Hi Jody,

Sorry for the late reply, just back from vacation :).

This all sounds reasonable. You are indeed correct that the proposal is not complete yet. I still have yet to get around to amending it with your original feedback. I will be sure to include this in it as well.

I will hopefully have it finished this week.

-Justin

Jody Garnett wrote:

Hi Justin; the WPS team went to try and use this proposal but it is not ready yet :frowning:

We tried talking about it in todays IRC meeting and got stalled out on the issue of having a maintainer.

The balance here is one of resources:
- on one side donating code to GeoServer cannot be a sentence to provide a staff member on call forever
- on the other side donating code to GeoServer does not mean the community will maintain the code for free

Andrea and I eventually worked out the compromise of either having a maintainer; or letting the PSC act like one (including kicking the module back to community status if needed). We both want to learn from the GeoTools experience of shapefile patches piling up in Jira.

It sounds like it too late for this procedure to be followed by the WPS team for this phase of the project. It would be very good if this procedure could be worked out prior to negotiating for continued work.

Cheers,
Jody

Jody Garnett wrote:

See earlier review of all the GSIP's there is some overlap between these two:
- http://geoserver.org/display/GEOS/GSIP+17+-+Community+module+handling
- http://geoserver.org/display/GEOS/GSIP+22+-+Extensions

Can this be resolved; or combined into a single policy change separating out the difference between how these are handled?
The GSIP+22 will need to change or define project build procedure; we should figure out what documentation pages
need to be updated?
- Can we have a procedure for "removing an extension"
- Since these are a lot more formal than community modules; can we get a wiki page with docs? Or even a formal installation/useage doc?

I am correct in thinking these are full fledged running modules (like WPS?) that are ready to go - they are just not in the default GeoServer download. As such I would like to hold them to the same high standard.

Jody
  
-------------------------------------------------------------------------
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

!DSPAM:4007,488f788e160291336712104!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

Thanks Justin;

We were just looking for a bar to jump over for our WPS work. If we can get this done before discussions start up for an additional phase to the project it would give us something to work from.

You may wish to review some strong words Andrea and I shared on the subject in an IRC meeting a couple of weeks ago. There is a tension between allowing people to take part; and preventing people dumping code and expecting it to be maintained. I don't mind what line we walk; I just want us to be clear about it. When we actually write up the procedure it may be a good communication tool to use a couple of examples.

Cheers,
Jody

Justin Deoliveira wrote:

Hi Jody,

Sorry for the late reply, just back from vacation :).

This all sounds reasonable. You are indeed correct that the proposal is not complete yet. I still have yet to get around to amending it with your original feedback. I will be sure to include this in it as well.

I will hopefully have it finished this week.
-Justin