Hi all,
today I've been adding the necessary unit testing to the
control flow module. The test coverage is above 70%.
I was wondering, what do you think of moving the module
to extension status? I would be the maintainer, testing is
there, I'll add docs in main documentation once the
module is in extensions.
There is a catch however. I cannot guarantee the configuration
of the module will be stable for a long time.
Maybe on the field testing will change our understanding
of what a good control flow is and we'll need to change
the way the module is configured (for sure I'll be adding
new types of flow controllers, one missing today is
a client IP address one).
But if this is not considered a problem I'll be happy
to move the control flow module to supported land.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Looking over the checklist of what it takes to a promote a community module:
http://docs.geoserver.org/2.0.x/en/developer/policies/community-modules.html#promoting-a-community-module
It seems most are satisfied. However #1 begs the question if the module has any users yet? Although I am interested in using it so perhaps I can count as one 
However I think #3 (the module is stable) is of more concern. It seems kind of strange to release something as officially supported but with the caveat that the configuration will not be stable.
Imo it would make more sense to let it live in community for a while until it gets a few more users and where there is a more stable idea of what the configuration will look like in the long term. And then officially move it.
Anyways, I know I don't get a vote on this but thought I would throw in my $0.02.
-Justin
On 2/9/10 1:57 PM, Andrea Aime wrote:
Hi all,
today I've been adding the necessary unit testing to the
control flow module. The test coverage is above 70%.
I was wondering, what do you think of moving the module
to extension status? I would be the maintainer, testing is
there, I'll add docs in main documentation once the
module is in extensions.
There is a catch however. I cannot guarantee the configuration
of the module will be stable for a long time.
Maybe on the field testing will change our understanding
of what a good control flow is and we'll need to change
the way the module is configured (for sure I'll be adding
new types of flow controllers, one missing today is
a client IP address one).
But if this is not considered a problem I'll be happy
to move the control flow module to supported land.
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
I fully agree with Justin on this one - its a positive to have Andrea
looking after it, but perhaps not the right signal to move something
based just on the quality of support. i think the community will
recognise that value without forcing it into extensions prematurely.
If there is an external driver to push something into supported status
then lets have a PSC discussion about the implications.
Rob
On Wed, Feb 10, 2010 at 6:12 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Looking over the checklist of what it takes to a promote a community module:
http://docs.geoserver.org/2.0.x/en/developer/policies/community-modules.html#promoting-a-community-module
It seems most are satisfied. However #1 begs the question if the module
has any users yet? Although I am interested in using it so perhaps I can
count as one
However I think #3 (the module is stable) is of more concern. It seems
kind of strange to release something as officially supported but with
the caveat that the configuration will not be stable.
Imo it would make more sense to let it live in community for a while
until it gets a few more users and where there is a more stable idea of
what the configuration will look like in the long term. And then
officially move it.
Anyways, I know I don't get a vote on this but thought I would throw in
my $0.02.
-Justin
On 2/9/10 1:57 PM, Andrea Aime wrote:
Hi all,
today I've been adding the necessary unit testing to the
control flow module. The test coverage is above 70%.
I was wondering, what do you think of moving the module
to extension status? I would be the maintainer, testing is
there, I'll add docs in main documentation once the
module is in extensions.
There is a catch however. I cannot guarantee the configuration
of the module will be stable for a long time.
Maybe on the field testing will change our understanding
of what a good control flow is and we'll need to change
the way the module is configured (for sure I'll be adding
new types of flow controllers, one missing today is
a client IP address one).
But if this is not considered a problem I'll be happy
to move the control flow module to supported land.
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
I am also in agreement. It seems early to be promoted yet. Have you had significant user feedback so far?
--
Mark
Rob Atkinson wrote:
I fully agree with Justin on this one - its a positive to have Andrea
looking after it, but perhaps not the right signal to move something
based just on the quality of support. i think the community will
recognise that value without forcing it into extensions prematurely.
If there is an external driver to push something into supported status
then lets have a PSC discussion about the implications.
Rob
On Wed, Feb 10, 2010 at 6:12 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Looking over the checklist of what it takes to a promote a community module:
http://docs.geoserver.org/2.0.x/en/developer/policies/community-modules.html#promoting-a-community-module
It seems most are satisfied. However #1 begs the question if the module
has any users yet? Although I am interested in using it so perhaps I can
count as one
However I think #3 (the module is stable) is of more concern. It seems
kind of strange to release something as officially supported but with
the caveat that the configuration will not be stable.
Imo it would make more sense to let it live in community for a while
until it gets a few more users and where there is a more stable idea of
what the configuration will look like in the long term. And then
officially move it.
Anyways, I know I don't get a vote on this but thought I would throw in
my $0.02.
-Justin
On 2/9/10 1:57 PM, Andrea Aime wrote:
Hi all,
today I've been adding the necessary unit testing to the
control flow module. The test coverage is above 70%.
I was wondering, what do you think of moving the module
to extension status? I would be the maintainer, testing is
there, I'll add docs in main documentation once the
module is in extensions.
There is a catch however. I cannot guarantee the configuration
of the module will be stable for a long time.
Maybe on the field testing will change our understanding
of what a good control flow is and we'll need to change
the way the module is configured (for sure I'll be adding
new types of flow controllers, one missing today is
a client IP address one).
But if this is not considered a problem I'll be happy
to move the control flow module to supported land.
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Mark Leslie wrote:
I am also in agreement. It seems early to be promoted yet. Have you had significant user feedback so far?
Chicken and egg. How do you get significant user feedback if there
is no release outlet for community modules? I can build a jar
and attach it to a blog post, the jar will work exclusively against
nightly builds and only as long as we don't change any dependency.
My current plan is to install the module on a busy server, then
blog about it and hope we'll get some feedback.
The module is there, I wrote a mail to the list with instructions
on how to use it but so far no one has tried it out, so I guess
I have to push on the users to get some real world feedback.
I'll get there
Cheers
Andrea
Perhaps we could generate two builds - one minimal and one maximal -
with all community extensions (and a mechanism for these to be
excluded if there is a known problem with it breaking the deployable)
- this would allow people to get experience with functionality on test
installations much easier.
Rob
On Thu, Feb 11, 2010 at 7:23 PM, Andrea Aime <aaime@anonymised.com> wrote:
Mark Leslie wrote:
I am also in agreement. It seems early to be promoted yet. Have you
had significant user feedback so far?
Chicken and egg. How do you get significant user feedback if there
is no release outlet for community modules? I can build a jar
and attach it to a blog post, the jar will work exclusively against
nightly builds and only as long as we don't change any dependency.
My current plan is to install the module on a busy server, then
blog about it and hope we'll get some feedback.
The module is there, I wrote a mail to the list with instructions
on how to use it but so far no one has tried it out, so I guess
I have to push on the users to get some real world feedback.
I'll get there
Cheers
Andrea
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Rob Atkinson wrote:
Perhaps we could generate two builds - one minimal and one maximal -
with all community extensions (and a mechanism for these to be
excluded if there is a known problem with it breaking the deployable)
- this would allow people to get experience with functionality on test
installations much easier.
A good compromise would be to include in the nigthly builds, but not in
the release, the modules that we want the community to evaluate more, those that are somehow scheduled for an inclusion in the extension
area.
That should allow the interested and adventurous users to try out the
modules without the need to build GeoServer from sources and would also
allow the generated jars to stay current with the modifications that might happen in core
Cheers
Andrea
Just to clarify are you suggesting that we:
a) build additional "community" artifacts like we do extensions
or
b) actually build the main release artifact so that it includes certain community modules?
I think (a) would make more sense but I believe would require additional release descriptor artifacts. Unless you plan to to bundle them up some other way?
On 2/11/10 6:21 AM, Andrea Aime wrote:
Rob Atkinson wrote:
Perhaps we could generate two builds - one minimal and one maximal -
with all community extensions (and a mechanism for these to be
excluded if there is a known problem with it breaking the deployable)
- this would allow people to get experience with functionality on test
installations much easier.
A good compromise would be to include in the nigthly builds, but not in
the release, the modules that we want the community to evaluate more,
those that are somehow scheduled for an inclusion in the extension
area.
That should allow the interested and adventurous users to try out the
modules without the need to build GeoServer from sources and would also
allow the generated jars to stay current with the modifications that
might happen in core
Cheers
Andrea
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
Just to clarify are you suggesting that we:
a) build additional "community" artifacts like we do extensions
or
b) actually build the main release artifact so that it includes certain community modules?
I think (a) would make more sense but I believe would require additional release descriptor artifacts. Unless you plan to to bundle them up some other way?
What I would like to have as a result is to have at:
http://gridlock.openplans.org/geoserver/2.0.x/
another subdirectory, call it sub-yyyy-mm-dd, with zips of
the community modules that we are trying to make people try out more.
In general a community module with have dependencies so a plain
jar won't do.
Or having those community jars in the usual ext-yyyy-mm-dd folder,
but make sure they don't get into a release.
I fear this in turn requires building some more release descriptors
for packaging, with the different that we'd keep them out in a profile
that has to be enabled manually?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
On 2/11/10 12:52 PM, Andrea Aime wrote:
Justin Deoliveira ha scritto:
Just to clarify are you suggesting that we:
a) build additional "community" artifacts like we do extensions
or
b) actually build the main release artifact so that it includes
certain community modules?
I think (a) would make more sense but I believe would require
additional release descriptor artifacts. Unless you plan to to bundle
them up some other way?
What I would like to have as a result is to have at:
http://gridlock.openplans.org/geoserver/2.0.x/
another subdirectory, call it sub-yyyy-mm-dd, with zips of
the community modules that we are trying to make people try out more.
In general a community module with have dependencies so a plain
jar won't do.
Or having those community jars in the usual ext-yyyy-mm-dd folder,
but make sure they don't get into a release.
I fear this in turn requires building some more release descriptors
for packaging, with the different that we'd keep them out in a profile
that has to be enabled manually?
Yeah, it is a bit of work. But how about this idea. We create a second release directory under "community". And can add release descriptors to it for those community modules that have a maintainer that is interested in seeing the module release for some testing as part of the nightly builds.
Assuming this maintainer will most likely want to see the module through to an extension they will have to do this eventually anyways.
So, when generating community module artifacts is the same process as generating the regular release artifacts, only executed from the community part of the tree.
We could also just add new artifact descriptors directly in the existing release directory but this does seem a nice way to isolate them.
If this is deemed a good idea I would be willing to help out with the part of creating the release directory under community. Just let me know.
-Justin
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.