[Geoserver-devel] Community modules proposal and the two pending modules (PSC people, please read and answer)

Hi,
I'm writing with regards to the community module handling.
The proposal still needs improvements, but at the same
time we have two potential community modules that have been
waiting.

One of them, the HTML image map extension, has been really waiting forever (2 months, omg... http://www.nabble.com/GeoServer-HTML-ImageMap-extension--to13237227.html#a13252566).

The other, SLD rest API, for about a week.

These times are way too long. We are in a situation where
we lack contributors, we don't need to setup barriers
for modules to enter community, but only to prevent them
for entering into the main distribution carelessly.
I don't know about you, but if I was in Mauro's place I would
be between the pissed off and the hope lost state of mind.

So what I'm proposing is that we:
* make the two modules enter the community section right away
   in the 1.6.x branch
* make it so entering the community section it's easy

To enter, we should only ask a review from a developer and
there you enter in the branch the module has been developed
for. The module won't be part of the build. To enter the
build the module would have to be building and be documented.
To become part of the distribution we would ask for more.

To avoid the mess, also exiting the community section should
be easy. If a module has been developed for a branch, it won't
be inserted into trunk unless the donor feels like mantaining
it there too. If a module has been developed for trunk, we wait
a stable release to eventually shake it off: when branching we
ask the developer if he's still ok mantaining it, if we don't
have a positive answer the module will be removed from trunk
(so it will stay on the stable branch only and be forgot once
the stable branch dies).

What do you think? The discussion on the procedures can
go on and on, we are in no hurry, what we should hurry for is
to allow those two people to get their contribution included
in GeoServer. Two months for a module to be accepted is bordering
ridiculous.

Cheers
Andrea

Hi Andrea,
I fully agree with your proposal.

Also the procedure seems fine to me, but this can be discussed further of course and hopefully come out with a detailed (but easy) procedure to get community modules quickly in.

On Dec 17, 2007 4:42 PM, Andrea Aime <aaime@anonymised.com> wrote:

Hi,
I’m writing with regards to the community module handling.
The proposal still needs improvements, but at the same
time we have two potential community modules that have been
waiting.

One of them, the HTML image map extension, has been really waiting
forever (2 months, omg…
http://www.nabble.com/GeoServer-HTML-ImageMap-extension–to13237227.html#a13252566 ).

The other, SLD rest API, for about a week.

These times are way too long. We are in a situation where
we lack contributors, we don’t need to setup barriers
for modules to enter community, but only to prevent them
for entering into the main distribution carelessly.
I don’t know about you, but if I was in Mauro’s place I would
be between the pissed off and the hope lost state of mind.

So what I’m proposing is that we:

  • make the two modules enter the community section right away
    in the 1.6.x branch
  • make it so entering the community section it’s easy

To enter, we should only ask a review from a developer and
there you enter in the branch the module has been developed
for. The module won’t be part of the build. To enter the
build the module would have to be building and be documented.
To become part of the distribution we would ask for more.

To avoid the mess, also exiting the community section should
be easy. If a module has been developed for a branch, it won’t
be inserted into trunk unless the donor feels like mantaining
it there too. If a module has been developed for trunk, we wait
a stable release to eventually shake it off: when branching we
ask the developer if he’s still ok mantaining it, if we don’t
have a positive answer the module will be removed from trunk
(so it will stay on the stable branch only and be forgot once
the stable branch dies).

What do you think? The discussion on the procedures can
go on and on, we are in no hurry, what we should hurry for is
to allow those two people to get their contribution included
in GeoServer. Two months for a module to be accepted is bordering
ridiculous.

Cheers
Andrea


SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It’s the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace


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


Andrea,

The proposal outlined at the "Community Module Handling" GSIP page
(http://docs.codehaus.org/display/GEOS/GSIP+17+-+Community+module
+handling) looks great to me.

I'd vote +1 at this point, if it were moved to voting.

--saul

On Mon, 2007-12-17 at 16:42 +0100, Andrea Aime wrote:

Hi,
I'm writing with regards to the community module handling.
The proposal still needs improvements, but at the same
time we have two potential community modules that have been
waiting.

One of them, the HTML image map extension, has been really waiting
forever (2 months, omg...
http://www.nabble.com/GeoServer-HTML-ImageMap-extension--to13237227.html#a13252566).

The other, SLD rest API, for about a week.

These times are way too long. We are in a situation where
we lack contributors, we don't need to setup barriers
for modules to enter community, but only to prevent them
for entering into the main distribution carelessly.
I don't know about you, but if I was in Mauro's place I would
be between the pissed off and the hope lost state of mind.

So what I'm proposing is that we:
* make the two modules enter the community section right away
   in the 1.6.x branch
* make it so entering the community section it's easy

To enter, we should only ask a review from a developer and
there you enter in the branch the module has been developed
for. The module won't be part of the build. To enter the
build the module would have to be building and be documented.
To become part of the distribution we would ask for more.

To avoid the mess, also exiting the community section should
be easy. If a module has been developed for a branch, it won't
be inserted into trunk unless the donor feels like mantaining
it there too. If a module has been developed for trunk, we wait
a stable release to eventually shake it off: when branching we
ask the developer if he's still ok mantaining it, if we don't
have a positive answer the module will be removed from trunk
(so it will stay on the stable branch only and be forgot once
the stable branch dies).

What do you think? The discussion on the procedures can
go on and on, we are in no hurry, what we should hurry for is
to allow those two people to get their contribution included
in GeoServer. Two months for a module to be accepted is bordering
ridiculous.

Cheers
Andrea

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Saul Farber ha scritto:

Andrea,

The proposal outlined at the "Community Module Handling" GSIP page
(http://docs.codehaus.org/display/GEOS/GSIP+17+-+Community+module
+handling) looks great to me.

I'd vote +1 at this point, if it were moved to voting.

Unfortunately last meeting people asked for more process, more
corner cases being handled, and I did not have time to improve
it (the usual stuff, I'm buried, high priority stuff kicks in
at any time, as a result it seems I cannot handle low priority
stuff that takes more than a couple of days and I just loose it...)

Cheeres
Andrea

Hi Andrea,

I agree that its unacceptable to have people held up on process for this
long. I give a +1 for instant access to svn directly after developer
review. And indeed for this case I think we should get them into svn asap.

That first step is crucial for allowing people to continue to work. And
it does not really affect us as the module is not in the build. Getting
into the build can perhaps be the second step after a formal proposal
has been done, a wiki page perhaps.

I also agree about making it responsibility of the maintainer to forward
port to new development branches.

But yeah, we can nail down process later, as for now, +1 on fast
tracking these modules.

-Justin

Andrea Aime wrote:

Hi,
I'm writing with regards to the community module handling.
The proposal still needs improvements, but at the same
time we have two potential community modules that have been
waiting.

One of them, the HTML image map extension, has been really waiting
forever (2 months, omg...
http://www.nabble.com/GeoServer-HTML-ImageMap-extension--to13237227.html#a13252566).

The other, SLD rest API, for about a week.

These times are way too long. We are in a situation where
we lack contributors, we don't need to setup barriers
for modules to enter community, but only to prevent them
for entering into the main distribution carelessly.
I don't know about you, but if I was in Mauro's place I would
be between the pissed off and the hope lost state of mind.

So what I'm proposing is that we:
* make the two modules enter the community section right away
   in the 1.6.x branch
* make it so entering the community section it's easy

To enter, we should only ask a review from a developer and
there you enter in the branch the module has been developed
for. The module won't be part of the build. To enter the
build the module would have to be building and be documented.
To become part of the distribution we would ask for more.

To avoid the mess, also exiting the community section should
be easy. If a module has been developed for a branch, it won't
be inserted into trunk unless the donor feels like mantaining
it there too. If a module has been developed for trunk, we wait
a stable release to eventually shake it off: when branching we
ask the developer if he's still ok mantaining it, if we don't
have a positive answer the module will be removed from trunk
(so it will stay on the stable branch only and be forgot once
the stable branch dies).

What do you think? The discussion on the procedures can
go on and on, we are in no hurry, what we should hurry for is
to allow those two people to get their contribution included
in GeoServer. Two months for a module to be accepted is bordering
ridiculous.

Cheers
Andrea

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,4766991a265172090977483!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org