Hi,
following the discussion about cleaning up the community modules I've
put togheter this wiki page listing community modules along with
whoever has still a stake in them and a column for comments:
http://geoserver.org/display/GEOS/May+2011+Community+modules+cleanup
I've tried to merge in David comments and added mine, if you are still
interested in a community module can you do the same and mark youself
as an interested party?
I'd say, let's have people populate this table for one week or so, and then
remove all modules that do not have anyone interested in them?
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------
Page updated with modules I care about. And question… are we going to outright remove the modules from svn… or move them to some other space outside the source tree. Reason being that there are a few in there that I probably don’t want to delete outright… but wouldn’t mind if they were outside the source tree. Modules that i probably won’t compile any time soon but if i want to look up something as a reference don’t want to really go hunting through the svn repository either.
On Sat, May 14, 2011 at 2:52 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
Hi,
following the discussion about cleaning up the community modules I’ve
put togheter this wiki page listing community modules along with
whoever has still a stake in them and a column for comments:
http://geoserver.org/display/GEOS/May+2011+Community+modules+cleanup
I’ve tried to merge in David comments and added mine, if you are still
interested in a community module can you do the same and mark youself
as an interested party?
I’d say, let’s have people populate this table for one week or so, and then
remove all modules that do not have anyone interested in them?
Cheers
Andrea
–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
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.
On Mon, May 16, 2011 at 4:10 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Page updated with modules I care about. And question... are we going to
outright remove the modules from svn... or move them to some other space
outside the source tree. Reason being that there are a few in there that I
probably don't want to delete outright.. but wouldn't mind if they were
outside the source tree. Modules that i probably won't compile any time soon
but if i want to look up something as a reference don't want to really go
hunting through the svn repository either.
If they are not recent we could just remove them from 2.1.x and trunk and
leave them on 2.0.x?
If they are recent I guess we could leave them only on trunk or
something like that,
and clean them up later if it needs be?
What worries me about moving them "outside" is that they lose the
connection with
the branch they were meant to be buildable into.
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------
On Mon, May 16, 2011 at 8:31 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Mon, May 16, 2011 at 4:10 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Page updated with modules I care about. And question… are we going to
outright remove the modules from svn… or move them to some other space
outside the source tree. Reason being that there are a few in there that I
probably don’t want to delete outright… but wouldn’t mind if they were
outside the source tree. Modules that i probably won’t compile any time soon
but if i want to look up something as a reference don’t want to really go
hunting through the svn repository either.
If they are not recent we could just remove them from 2.1.x and trunk and
leave them on 2.0.x?
Yup, that works too. Although if we want to keep things a little cleaner moving forward we might consider not including any community modules when we fork out a stable branch.
If they are recent I guess we could leave them only on trunk or
something like that,
and clean them up later if it needs be?
What worries me about moving them “outside” is that they lose the
connection with
the branch they were meant to be buildable into.
Fair enough. No strong opinion on my side. I was pretty conservative about marking modules with interest so they’ll stay in community for now.
Cheers
Andrea
–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
On Mon, May 16, 2011 at 4:49 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
If they are not recent we could just remove them from 2.1.x and trunk and
leave them on 2.0.x?
Yup, that works too. Although if we want to keep things a little cleaner
moving forward we might consider not including any community modules when we
fork out a stable branch.
What about those modules that are trying to graduate, and those that we added
to the night build?
I'm afraid many people would just not try them out if they are associated only
to a trunk nightly build, you'd mix a new module growing up with a known to
be unstable GS build.
If they are recent I guess we could leave them only on trunk or
something like that,
and clean them up later if it needs be?
What worries me about moving them "outside" is that they lose the
connection with
the branch they were meant to be buildable into.
Fair enough. No strong opinion on my side. I was pretty conservative about
marking modules with interest so they'll stay in community for now.
Cool
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------
Exceptionally good point. I had not considered that.
On 16/05/11 22:31, Andrea Aime wrote:
What worries me about moving them "outside" is that they lose the
connection with
the branch they were meant to be buildable into.
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
Hi guys,
checked and updated the page too … safe to go on my side.
Alessio.
Ing. Alessio Fabiani
Founder / CTO GeoSolutions S.A.S.
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: (+39) 0584 96.23.13
fax: (+39) 0584 96.23.13
mobile:(+39) 331 62.33.686
On Tue, May 17, 2011 at 3:48 AM, Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com wrote:
Exceptionally good point. I had not considered that.
On 16/05/11 22:31, Andrea Aime wrote:
What worries me about moving them “outside” is that they lose the
connection with
the branch they were meant to be buildable into.
–
Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel