[Geoserver-devel] GeoServer QA: asking users to help out?

GeoServer GeoServer Developer
,
1

Hi all (devs and users lurking alike),
I'm writing this mail to see if we can, as a community, improve
the level of testing each GeoServer release gets before
being released.

GeoServer QA improve a lot since two years ago, we now have
thousands of tests running during the builds, continuous
build servers checking each commit, work is underway to
run this checks on other OS/JVM, we run quite a number
of OGC CITE test suites before each release.

Despite our best efforts some obvious bugs slip in.
What we need is some interactive testing, real world,
against existing applications, made by human beings.
People trying to configure new layers, test the
release against their production setup, check various
client applications do work.

We have quite a large user community out there (900+
subcscribers on the users ml last time I checked), if
only a few of them stepped in to become testers it could
make a large difference. Maybe someone is interested in keeping
GS working fine with uDig, or with QGis, or just check their
in house application works as expected. Someone else might
be interested in something more formalized, like manual test
scripts to be executed against a release candidate, but imho
it would be better if people would self organise and find
some kind of testing they have an interest into running.

If some users are interested in doing this we could have
a "pens up" period of maybe 2-3 days before a release in
which those adventurers test nightlies and report regressions
(to be fixed) and new bugs (to be evaluated by severity).

Developers, what do you think?
Users, I know quite some of you are lurking on this mailing
list to "check the pulse" of the development and see what's
boiling in the pot. This could be an occasion to step up
your involvement and work for a better GeoServer.

Comments?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

2

I would be delighted to run my test suite and test some apps here during
the "pens up" period for each release.
Even if I wasn't planning to upgrade, it helps me to find any issues
that affect "my stuff" as early as possible.

-----Original Message-----
From: geoserver-devel-bounces@lists.sourceforge.net
[mailto:geoserver-devel-bounces@lists.sourceforge.net] On Behalf Of
Andrea Aime
Sent: Tuesday, August 25, 2009 11:13 AM
To: Geoserver-devel
Subject: [Geoserver-devel] GeoServer QA: asking users to help out?

Hi all (devs and users lurking alike),
I'm writing this mail to see if we can, as a community, improve the
level of testing each GeoServer release gets before being released.

GeoServer QA improve a lot since two years ago, we now have thousands of
tests running during the builds, continuous build servers checking each
commit, work is underway to run this checks on other OS/JVM, we run
quite a number of OGC CITE test suites before each release.

Despite our best efforts some obvious bugs slip in.
What we need is some interactive testing, real world, against existing
applications, made by human beings.
People trying to configure new layers, test the release against their
production setup, check various client applications do work.

We have quite a large user community out there (900+ subcscribers on the
users ml last time I checked), if only a few of them stepped in to
become testers it could make a large difference. Maybe someone is
interested in keeping GS working fine with uDig, or with QGis, or just
check their in house application works as expected. Someone else might
be interested in something more formalized, like manual test scripts to
be executed against a release candidate, but imho it would be better if
people would self organise and find some kind of testing they have an
interest into running.

If some users are interested in doing this we could have a "pens up"
period of maybe 2-3 days before a release in which those adventurers
test nightlies and report regressions (to be fixed) and new bugs (to be
evaluated by severity).

Developers, what do you think?
Users, I know quite some of you are lurking on this mailing list to
"check the pulse" of the development and see what's boiling in the pot.
This could be an occasion to step up your involvement and work for a
better GeoServer.

Comments?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------
------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day trial. Simplify your report design, integration and deployment -
and focus on what you do best, core application coding. Discover what's
new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

I am always ready to run through the udig walkthroughs with geoserver;
a formal pens up period would help me know when to test.

lately I have been testing as I release uDig which is not nearly as helpful.

Jody

On Wed, Aug 26, 2009 at 1:41 AM, Freeman, Aleda
(EEA)<Aleda.Freeman@anonymised.com> wrote:

I would be delighted to run my test suite and test some apps here during
the "pens up" period for each release.
Even if I wasn't planning to upgrade, it helps me to find any issues
that affect "my stuff" as early as possible.

-----Original Message-----
From: geoserver-devel-bounces@lists.sourceforge.net
[mailto:geoserver-devel-bounces@lists.sourceforge.net] On Behalf Of
Andrea Aime
Sent: Tuesday, August 25, 2009 11:13 AM
To: Geoserver-devel
Subject: [Geoserver-devel] GeoServer QA: asking users to help out?

Hi all (devs and users lurking alike),
I'm writing this mail to see if we can, as a community, improve the
level of testing each GeoServer release gets before being released.

GeoServer QA improve a lot since two years ago, we now have thousands of
tests running during the builds, continuous build servers checking each
commit, work is underway to run this checks on other OS/JVM, we run
quite a number of OGC CITE test suites before each release.

Despite our best efforts some obvious bugs slip in.
What we need is some interactive testing, real world, against existing
applications, made by human beings.
People trying to configure new layers, test the release against their
production setup, check various client applications do work.

We have quite a large user community out there (900+ subcscribers on the
users ml last time I checked), if only a few of them stepped in to
become testers it could make a large difference. Maybe someone is
interested in keeping GS working fine with uDig, or with QGis, or just
check their in house application works as expected. Someone else might
be interested in something more formalized, like manual test scripts to
be executed against a release candidate, but imho it would be better if
people would self organise and find some kind of testing they have an
interest into running.

If some users are interested in doing this we could have a "pens up"
period of maybe 2-3 days before a release in which those adventurers
test nightlies and report regressions (to be fixed) and new bugs (to be
evaluated by severity).

Developers, what do you think?
Users, I know quite some of you are lurking on this mailing list to
"check the pulse" of the development and see what's boiling in the pot.
This could be an occasion to step up your involvement and work for a
better GeoServer.

Comments?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------
------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day trial. Simplify your report design, integration and deployment -
and focus on what you do best, core application coding. Discover what's
new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

4

I think it is a great idea, crowdsourcing qa to the user community. However I think one thing that is lacking (or maybe just not emphasized) are the the benefits to the users. Any issues they find will become critical priority (i would assume) and fixed before the release (if within reason). This has the potential to offset a lot of risk of people upgrading.

Andrea Aime wrote:

Hi all (devs and users lurking alike),
I'm writing this mail to see if we can, as a community, improve
the level of testing each GeoServer release gets before
being released.

GeoServer QA improve a lot since two years ago, we now have
thousands of tests running during the builds, continuous
build servers checking each commit, work is underway to
run this checks on other OS/JVM, we run quite a number
of OGC CITE test suites before each release.

Despite our best efforts some obvious bugs slip in.
What we need is some interactive testing, real world,
against existing applications, made by human beings.
People trying to configure new layers, test the
release against their production setup, check various
client applications do work.

We have quite a large user community out there (900+
subcscribers on the users ml last time I checked), if
only a few of them stepped in to become testers it could
make a large difference. Maybe someone is interested in keeping
GS working fine with uDig, or with QGis, or just check their
in house application works as expected. Someone else might
be interested in something more formalized, like manual test
scripts to be executed against a release candidate, but imho
it would be better if people would self organise and find
some kind of testing they have an interest into running.

If some users are interested in doing this we could have
a "pens up" period of maybe 2-3 days before a release in
which those adventurers test nightlies and report regressions
(to be fixed) and new bugs (to be evaluated by severity).

Developers, what do you think?
Users, I know quite some of you are lurking on this mailing
list to "check the pulse" of the development and see what's
boiling in the pot. This could be an occasion to step up
your involvement and work for a better GeoServer.

Comments?

Cheers
Andrea

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

5

Justin Deoliveira ha scritto:

I think it is a great idea, crowdsourcing qa to the user community. However I think one thing that is lacking (or maybe just not emphasized) are the the benefits to the users. Any issues they find will become critical priority (i would assume) and fixed before the release (if within reason). This has the potential to offset a lot of risk of people upgrading.

I thought about it, but was cautious about adding such point.
Why are developers participating? To get a better GeoServer.
Do we really need to give users more incentive?

I agree regressions should be fixed swiftly, but what if during testing
a new bug is spotted, or it's something affecting a minor
extension? Do we "stop the presses" for any of those?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

6

Andrea Aime wrote:

Justin Deoliveira ha scritto:

I think it is a great idea, crowdsourcing qa to the user community. However I think one thing that is lacking (or maybe just not emphasized) are the the benefits to the users. Any issues they find will become critical priority (i would assume) and fixed before the release (if within reason). This has the potential to offset a lot of risk of people upgrading.

I thought about it, but was cautious about adding such point.
Why are developers participating? To get a better GeoServer.
Do we really need to give users more incentive?

I agree regressions should be fixed swiftly, but what if during testing
a new bug is spotted, or it's something affecting a minor
extension? Do we "stop the presses" for any of those?

Fair enough, valid concerns. I just don't think the idea will get much uptake unless there is more of a bounty.

Cheers
Andrea

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

7

Justin Deoliveira ha scritto:

Andrea Aime wrote:

Justin Deoliveira ha scritto:

I think it is a great idea, crowdsourcing qa to the user community. However I think one thing that is lacking (or maybe just not emphasized) are the the benefits to the users. Any issues they find will become critical priority (i would assume) and fixed before the release (if within reason). This has the potential to offset a lot of risk of people upgrading.

I thought about it, but was cautious about adding such point.
Why are developers participating? To get a better GeoServer.
Do we really need to give users more incentive?

I agree regressions should be fixed swiftly, but what if during testing
a new bug is spotted, or it's something affecting a minor
extension? Do we "stop the presses" for any of those?

Fair enough, valid concerns. I just don't think the idea will get much uptake unless there is more of a bounty.

If we specify that regressions found in the 2 days pen down period
are fixed before the release it's better, like, bounty enough?
It makes it clear they do get something.

Otherwise, if I'm a smart user, I find a bug, I wait to report
in the pen down period and ta-da!, whatever the bug is the
developers are bound to fix it. Does not look like a very nice
outcome to me :wink:

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

8

hello all,

i'm one of those users "...lurking on this mailing list to 'check the
pulse' of the development" as Andrea put it :slight_smile:

i agree it's a great idea and am willing to help, but pls. consider this:

* we include GeoServer in our application but we can not, or do not,
always include the latest released version --for lots of reasons that
cannot be discussed here. the end result is that while for example the
current GeoServer is at version 2.0 (unstable) / 1.7.6 (stable), we have
installations out there that have GeoServer versions 1.5.4b and 1.6.4b!

* 2-3 days testing is not enough. for my type of application, at least
1-week is more like it. having a 4-6 weeks notice would also mean that
this testing period can be better planned.

* may be listing the general aspects/features that Users are interested
in (and are invited to) testing would also help describe the coverage of
the tests. such a list could include: WMS <version>, WFS <version>,
WFS-T <version>, WCS <version>, Datastore Extension <type>,
installation, administration, documentation, REST, GeoWebCache, I18N,
<extension>s, etc... also by OS.

* while this is not completely related to the idea of Users helping w/
testing, i think it affects the Quality of GeoServer releases: i would
like to see an official "end-of-maintenance" date for every GeoServer
official release. this should not hinder the concept of "release often"
but IMO would improve the Quality factor of the/any release. of course
it may add a burden on the developers when deciding about new features,
bug fixes, etc... but again IMO it would increase the already high
quality of the GeoServer product.

Justin Deoliveira wrote:

I think it is a great idea, crowdsourcing qa to the user community.
However I think one thing that is lacking (or maybe just not emphasized)
are the the benefits to the users. Any issues they find will become
critical priority (i would assume) and fixed before the release (if
within reason). This has the potential to offset a lot of risk of people
upgrading.

Andrea Aime wrote:

Hi all (devs and users lurking alike),
I'm writing this mail to see if we can, as a community, improve
the level of testing each GeoServer release gets before
being released.

GeoServer QA improve a lot since two years ago, we now have
thousands of tests running during the builds, continuous
build servers checking each commit, work is underway to
run this checks on other OS/JVM, we run quite a number
of OGC CITE test suites before each release.

Despite our best efforts some obvious bugs slip in.
What we need is some interactive testing, real world,
against existing applications, made by human beings.
People trying to configure new layers, test the
release against their production setup, check various
client applications do work.

We have quite a large user community out there (900+
subcscribers on the users ml last time I checked), if
only a few of them stepped in to become testers it could
make a large difference. Maybe someone is interested in keeping
GS working fine with uDig, or with QGis, or just check their
in house application works as expected. Someone else might
be interested in something more formalized, like manual test
scripts to be executed against a release candidate, but imho
it would be better if people would self organise and find
some kind of testing they have an interest into running.

If some users are interested in doing this we could have
a "pens up" period of maybe 2-3 days before a release in
which those adventurers test nightlies and report regressions
(to be fixed) and new bugs (to be evaluated by severity).

Developers, what do you think?
Users, I know quite some of you are lurking on this mailing
list to "check the pulse" of the development and see what's
boiling in the pot. This could be an occasion to step up
your involvement and work for a better GeoServer.

Comments?

Cheers
Andrea

--
cheers;
rsn

9

Raif S. Naffah ha scritto:

hello all,

i'm one of those users "...lurking on this mailing list to 'check the
pulse' of the development" as Andrea put it :slight_smile:

i agree it's a great idea and am willing to help, but pls. consider this:

* we include GeoServer in our application but we can not, or do not,
always include the latest released version --for lots of reasons that
cannot be discussed here. the end result is that while for example the
current GeoServer is at version 2.0 (unstable) / 1.7.6 (stable), we have
installations out there that have GeoServer versions 1.5.4b and 1.6.4b!

Both dead for a long time

* 2-3 days testing is not enough. for my type of application, at least
1-week is more like it. having a 4-6 weeks notice would also mean that
this testing period can be better planned.

Our current release cycle is "once per month", so of course 4 weeks
in not possible. One week could be, thought I have some reservation
on it as people would use the week from end to end, so we'd end up
with something like 10 days of stopped development.
I guess we could tag the release in both gt2 and gs svn and treat the
tags as mini branches... which would make for a "3 branches" development
for a short time. My gut feeling says "no, too much work", but I'm
happy to be convinced otherwise, especially if there is support from
other developers to the idea and the associated extra burden.

* may be listing the general aspects/features that Users are interested
in (and are invited to) testing would also help describe the coverage of
the tests. such a list could include: WMS <version>, WFS <version>,
WFS-T <version>, WCS <version>, Datastore Extension <type>,
installation, administration, documentation, REST, GeoWebCache, I18N,
<extension>s, etc... also by OS.

Getting people to test GeoServer is already hard, I think we'd be
more than happy to get any testing that people feel like doing,
whatever it is (e.g., it could be integration testing against
your application, something that you care more about and thus have
better interest in doing).
If a testing group forms and there is a believe some manual testing
script is beneficial some of the poeple could write it and use it,
but I feel telling people what to test might hinder participation.
So my feeling is that testing scripts and directions are a good idea,
but people should be free to test in whatever manner they feel it's
better for them.

* while this is not completely related to the idea of Users helping w/
testing, i think it affects the Quality of GeoServer releases: i would
like to see an official "end-of-maintenance" date for every GeoServer
official release. this should not hinder the concept of "release often"
but IMO would improve the Quality factor of the/any release. of course
it may add a burden on the developers when deciding about new features,
bug fixes, etc... but again IMO it would increase the already high
quality of the GeoServer product.

Historically each series reached end of development when the new series
is released as stable. So for example 1.6.x died when 1.7.0 was released.
That is, unless someone decides to step up and back port interesting
bug fixes to the 1.7.x series and make releases. Lisasoft expressed
some interest in that and is helping with the current 1.7.x releases,
which the dev team would have already abandoned otherwise (so thank
you Lisasoft, 1.7.6 might not have been there without your help).

As an alternative there are commercial support companies that can
be "persuaded" to port back selected bug fixes and make further releases
out of dead branches.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

10

current GeoServer is at version 2.0 (unstable) / 1.7.6 (stable), we have
installations out there that have GeoServer versions 1.5.4b and 1.6.4b!

Both dead for a long time

Dead may be too strong a word; a critical patch done for a paying
customer would be fine. The difficulty is that the developers no
longer have a checkout; so there is an over head associated with
grabbing the code; making a fix; deploying it for someone to test; and
then finally issuing a dot release. These overheads add up restricting
it to a paid activity.

It is also worth noting that these overheads are not present in when
working on trunk since a release will be coming out later in the
month; making it much cheaper for everyone to be involved.

* 2-3 days testing is not enough. for my type of application, at least
1-week is more like it. having a 4-6 weeks notice would also mean that
this testing period can be better planned.

From our standpoint it is worth asking you to put in that kind of

effort for the 2.0 release. My fear is that your team will try testing
in earnest after the release has gone out when it is much more
expensive to fix; especially with respect to any API changes.

If your team can test your application against a "sample" 2.0 release
the changes between 2.0.1, 2.0.2 etc will be much smaller in nature.

bug fixes to the 1.7.x series and make releases. Lisasoft expressed
some interest in that and is helping with the current 1.7.x releases,
which the dev team would have already abandoned otherwise (so thank
you Lisasoft, 1.7.6 might not have been there without your help).

We are actual in the same neck of the woods as Raif - so if you want
to join us in making the next 1.7.x release come on over and we will
buy beer.

Actually Raif I am having trouble hunting down a location for an extra
day of code sprint. If possible I would like to corner the deegree
developers and get an initial cut of the geometry module out while
everyone is in the same city. Is there any chance we could hack at
your offices on the Sunday after the conference?

As an alternative there are commercial support companies that can
be "persuaded" to port back selected bug fixes and make further releases
out of dead branches.

Just so.

Jody

11

hello Jody,

my comments are in-lined

Jody Garnett wrote:

current GeoServer is at version 2.0 (unstable) / 1.7.6 (stable), we have
installations out there that have GeoServer versions 1.5.4b and 1.6.4b!

Both dead for a long time

Dead may be too strong a word; a critical patch done for a paying
customer would be fine. The difficulty is that the developers no
longer have a checkout; so there is an over head associated with
grabbing the code; making a fix; deploying it for someone to test; and
then finally issuing a dot release. These overheads add up restricting
it to a paid activity.

It is also worth noting that these overheads are not present in when
working on trunk since a release will be coming out later in the
month; making it much cheaper for everyone to be involved.

noted. i was trying to make the point that there's a time lag between a release of a (really stable) version of GeoServer and a similar one for a product that includes that version. in my case the product in question does not have a once-a-month release.

* 2-3 days testing is not enough. for my type of application, at least
1-week is more like it. having a 4-6 weeks notice would also mean that
this testing period can be better planned.

From our standpoint it is worth asking you to put in that kind of
effort for the 2.0 release. My fear is that your team will try testing
in earnest after the release has gone out when it is much more
expensive to fix; especially with respect to any API changes.

If your team can test your application against a "sample" 2.0 release
the changes between 2.0.1, 2.0.2 etc will be much smaller in nature.

bug fixes to the 1.7.x series and make releases. Lisasoft expressed
some interest in that and is helping with the current 1.7.x releases,
which the dev team would have already abandoned otherwise (so thank
you Lisasoft, 1.7.6 might not have been there without your help).

We are actual in the same neck of the woods as Raif - so if you want
to join us in making the next 1.7.x release come on over and we will
buy beer.

cool! moving from 1.5/1.6 to 1.7 sounds less risky for me than to 2.0 right now. spending time on testing 1.7 releases in my case is a better value proposition. let me know when the next round is about to start.

Actually Raif I am having trouble hunting down a location for an extra
day of code sprint. If possible I would like to corner the deegree
developers and get an initial cut of the geometry module out while
everyone is in the same city. Is there any chance we could hack at
your offices on the Sunday after the conference?

i'll talk to you about this off the list.

As an alternative there are commercial support companies that can
be "persuaded" to port back selected bug fixes and make further releases
out of dead branches.

Just so.

cheers;
rsn

12

Jody Garnett ha scritto:

current GeoServer is at version 2.0 (unstable) / 1.7.6 (stable), we have
installations out there that have GeoServer versions 1.5.4b and 1.6.4b!

Both dead for a long time

Dead may be too strong a word; a critical patch done for a paying
customer would be fine. The difficulty is that the developers no
longer have a checkout; so there is an over head associated with
grabbing the code; making a fix; deploying it for someone to test; and
then finally issuing a dot release. These overheads add up restricting
it to a paid activity.

It is also worth noting that these overheads are not present in when
working on trunk since a release will be coming out later in the
month; making it much cheaper for everyone to be involved.

Yeah, this is pretty much what I meant when I said "dead". Given the
availability of source code and the tools needed there is no project
that cannot be resurrected and patched (especially when there is still
people familiar with it around).

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

13

noted. i was trying to make the point that there's a time lag between a release of a (really stable) version of GeoServer and a similar one for a product that includes that version. in my case the product in question does not have a once-a-month release.

Understood; even if you can kick the tires for a couple of days with a RnD version of your product it will give you good information to plan with and help catch any regressions that only your software will notice.

to join us in making the next 1.7.x release come on over and we will
buy beer.

cool! moving from 1.5/1.6 to 1.7 sounds less risky for me than to 2.0 right now. spending time on testing 1.7 releases in my case is a better value proposition. let me know when the next round is about to start.

I suspect that moving to 1.7 is the major risk for your app. New feature model, new config subsystem etc. 2.0 by comparison is more focused on an amazing user interface :slight_smile:

All the best,
Jody

14

Jody Garnett ha scritto:

noted. i was trying to make the point that there's a time lag between a release of a (really stable) version of GeoServer and a similar one for a product that includes that version. in my case the product in question does not have a once-a-month release.

Understood; even if you can kick the tires for a couple of days with a RnD version of your product it will give you good information to plan with and help catch any regressions that only your software will notice.

to join us in making the next 1.7.x release come on over and we will
buy beer.

cool! moving from 1.5/1.6 to 1.7 sounds less risky for me than to 2.0 right now. spending time on testing 1.7 releases in my case is a better value proposition. let me know when the next round is about to start.

I suspect that moving to 1.7 is the major risk for your app. New feature model, new config subsystem etc. 2.0 by comparison is more focused on an amazing user interface :slight_smile:

Err... the new feature model had little or not impact on GeoServer,
we basically had no defect reports over it.
Most of the new config subsystem issues were sorted out in the first
releases of the series.
2.0 is still showing issues in the config subsystem. The risk going
there is significantly higher than going 1.7.6

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

15

Hi all,

I’m Francesco Izzi and i’m technical lead of geoSDI project.

geoSDI is a programme coordinated by the Italian Department for Civil Protection, aimed to the design and todevelop of the Italian National Spatial Data Infrastructure, according to the provisions of the Inspire Directive, using open source software applications.

It is developed by the Institute for the Methodologies of Environmental Analysis (IMAA) of the Italian National Research Council (CNR) with the collaboration of most of the national institutions concerned.

The whole geoSDI project was built fully in line with the Open Geospatial Consortium Standards and is therefore compatible and interoperable with other Spatial Data Infrastructure tools possibly being used by other Civil Protection actors in the international scenario.

geoSDI uses GeoServer for sharing geospatial data inside the Italian National Civil Protection Spatial Data Infrastructure.

For improving the required performances and availability in the OGC open web services delivery, a cluster configuration of GeoServer with load balancing has been performed and remarkable results have been appreciated.

Given our massive and continuous use of GeoServer, we would be honored to join the GeoServer testing team.

Cheers
Francesco.

2009/9/4 Andrea Aime <aaime@anonymised.com>

Jody Garnett ha scritto:

noted. i was trying to make the point that there’s a time lag between
a release of a (really stable) version of GeoServer and a similar one
for a product that includes that version. in my case the product in
question does not have a once-a-month release.

Understood; even if you can kick the tires for a couple of days with a
RnD version of your product it will give you good information to plan
with and help catch any regressions that only your software will notice.

to join us in making the next 1.7.x release come on over and we will
buy beer.

cool! moving from 1.5/1.6 to 1.7 sounds less risky for me than to 2.0
right now. spending time on testing 1.7 releases in my case is a
better value proposition. let me know when the next round is about to
start.

I suspect that moving to 1.7 is the major risk for your app. New feature
model, new config subsystem etc. 2.0 by comparison is more focused on an
amazing user interface :slight_smile:

Err… the new feature model had little or not impact on GeoServer,
we basically had no defect reports over it.
Most of the new config subsystem issues were sorted out in the first
releases of the series.
2.0 is still showing issues in the config subsystem. The risk going
there is significantly higher than going 1.7.6

Cheers
Andrea

–
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what’s new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july

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

–
Francesco Izzi
CNR - IMAA
geoSDI - NSDI
Responsabile Sviluppo Software

C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia

phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3402640314
mail: francesco.izzi@anonymised.com
skype: neofx8080

web: http://www.geosdi.org