Hi all,
following up the data dir handling issues me, Brent
and Justin had a quick chat and I think we have a
compelling proposal, which has been distilled in:
http://docs.codehaus.org/display/GEOS/GSIP+11+-+Data+configuration+handling
Hopefully we'll be able to vote it during the next
Geoserver meeting.
Feedback welcomed here, on the ml.
Cheers
Andrea
Comment attached. Will past in here for discussion:
I would like to keep the svn layout as is, as it is the standard way to layout an svn repository. Instead just create another directory under the root of the repository called "config". So repo layout looks like:
svn.codehaus.org/geoserver
+ trunk
+ branches
+ tags
+ config
+ release
+ minimal
...
-Justin
Andrea Aime wrote:
Hi all,
following up the data dir handling issues me, Brent
and Justin had a quick chat and I think we have a
compelling proposal, which has been distilled in:
http://docs.codehaus.org/display/GEOS/GSIP+11+-+Data+configuration+handlingHopefully we'll be able to vote it during the next
Geoserver meeting.
Feedback welcomed here, on the ml.Cheers
Andrea-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:1004,45b8f23064991995013331!
--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org
Justin Deoliveira ha scritto:
Comment attached. Will past in here for discussion:
I would like to keep the svn layout as is, as it is the standard way to layout an svn repository. Instead just create another directory under the root of the repository called "config". So repo layout looks like:
svn.codehaus.org/geoserver
+ trunk
+ branches
+ tags
+ config
+ release
+ minimal
...
Nicer for us, for sure. Tempting. 
As a developer in South Africa, how would you checkout geoserver
without checking out the config directory? By checking out each
module one by one?
Cheers
Andrea
Justin Deoliveira ha scritto:
Comment attached. Will past in here for discussion:
I would like to keep the svn layout as is, as it is the standard way to layout an svn repository. Instead just create another directory under the root of the repository called "config". So repo layout looks like:
svn.codehaus.org/geoserver
+ trunk
+ branches
+ tags
+ config
+ release
+ minimal
Ah sorry, I misread your mail (it's getting late here...)
How would you handle branches this way?
The config is something that's related to the geoserver
version you're playing with.
For example, config dirs for 1.5.x are incompatible with 1.4.x
and the opposite is (sadly) true as well (GEoserver is not
happy that there are no wcs elements in the services.xml
afaik).
Cheers
Andrea
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Comment attached. Will past in here for discussion:
I would like to keep the svn layout as is, as it is the standard way to layout an svn repository. Instead just create another directory under the root of the repository called "config". So repo layout looks like:
svn.codehaus.org/geoserver
+ trunk
+ branches
+ tags
+ config
+ release
+ minimalAh sorry, I misread your mail (it's getting late here...)
How would you handle branches this way?
The config is something that's related to the geoserver
version you're playing with.
For example, config dirs for 1.5.x are incompatible with 1.4.x
and the opposite is (sadly) true as well (GEoserver is not
happy that there are no wcs elements in the services.xml
afaik).
That's bad. Is there any way we can get that to work?
Cheers
Andrea-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:1003,45b8fd8475031429667743!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
...
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Comment attached. Will past in here for discussion:
I would like to keep the svn layout as is, as it is the standard way to layout an svn repository. Instead just create another directory under the root of the repository called "config". So repo layout looks like:
svn.codehaus.org/geoserver
+ trunk
+ branches
+ tags
+ config
+ release
+ minimal
Ah sorry, I misread your mail (it's getting late here...)
How would you handle branches this way?
The config is something that's related to the geoserver
version you're playing with.
For example, config dirs for 1.5.x are incompatible with 1.4.x
and the opposite is (sadly) true as well (GEoserver is not
happy that there are no wcs elements in the services.xml
afaik).
correct. If I use a 1.4 data directory then a 1.5 version of GeoServer will die. We should probably fix this actually, or throw an appropriate error that says something along the lines of "It looks like you are using an older data directory, you should use one appropriate for this version."
Although I think we have to maintain some sort of backwards compatibility, as this is why we have the data directory: so people can just point a new version at their old data directory. hmm, I will file a bug report.
Cheers
Andrea
Brent Owens
(The Open Planning Project)
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Chris Holmes ha scritto:
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Comment attached. Will past in here for discussion:
I would like to keep the svn layout as is, as it is the standard way to layout an svn repository. Instead just create another directory under the root of the repository called "config". So repo layout looks like:
svn.codehaus.org/geoserver
+ trunk
+ branches
+ tags
+ config
+ release
+ minimalAh sorry, I misread your mail (it's getting late here...)
How would you handle branches this way?
The config is something that's related to the geoserver
version you're playing with.
For example, config dirs for 1.5.x are incompatible with 1.4.x
and the opposite is (sadly) true as well (GEoserver is not
happy that there are no wcs elements in the services.xml
afaik).That's bad. Is there any way we can get that to work?
Don't know at the moment, it all boils do to have the config
system handle optional elements and provide defaults.
Opened http://jira.codehaus.org/browse/GEOS-877 to handle this.
Cheers
Andrea
PS: I should have opened this before... too many things going on,
I do loose bits here and there
Thinking ... you guys are moving too quickly for me these days. I think I need to spend some time with before and after architecture pictures (I hate design discussion in the small with consequenes in the large).
So let me define the large:
- how do I run with no data directory
- how do I cluster the resulting GeoServer
Jody
Hi all,
following up the data dir handling issues me, Brent
and Justin had a quick chat and I think we have a
compelling proposal, which has been distilled in:
http://docs.codehaus.org/display/GEOS/GSIP+11+-+Data+configuration+handlingHopefully we'll be able to vote it during the next
Geoserver meeting.
Feedback welcomed here, on the ml.Cheers
Andrea-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Of course now that I read the page I find we are talking about svn and our build process. This is not really a subject for a GSIP; let's fix build problems as they arrise and leave GSIP for decisions with strategic consequences for GeoServer as a product / project.
Cheers,
Jody
Hi all,
following up the data dir handling issues me, Brent
and Justin had a quick chat and I think we have a
compelling proposal, which has been distilled in:
http://docs.codehaus.org/display/GEOS/GSIP+11+-+Data+configuration+handlingHopefully we'll be able to vote it during the next
Geoserver meeting.
Feedback welcomed here, on the ml.Cheers
Andrea-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Hmm, fair enough. I guess I thought that config directories would be something that cut across geoserver versions and branches. In that case I would prefer either of the following
1.
svn.codehaus.org/geoserver
+ trunk
+ branches
+ tags
+ config
+ trunk
+ branches
+ tags
Or
2.
svn.codehaus.org/geoserver
+ trunk
+ geoserver
+ config
+ branches
+ tags
+ config
I guess #2 is more or less the original proposal.
-Justin
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Comment attached. Will past in here for discussion:
I would like to keep the svn layout as is, as it is the standard way to layout an svn repository. Instead just create another directory under the root of the repository called "config". So repo layout looks like:
svn.codehaus.org/geoserver
+ trunk
+ branches
+ tags
+ config
+ release
+ minimalAh sorry, I misread your mail (it's getting late here...)
How would you handle branches this way?
The config is something that's related to the geoserver
version you're playing with.
For example, config dirs for 1.5.x are incompatible with 1.4.x
and the opposite is (sadly) true as well (GEoserver is not
happy that there are no wcs elements in the services.xml
afaik).Cheers
Andrea-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:1004,45b8fd8475021460912952!
--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org
Jody Garnett ha scritto:
Of course now that I read the page I find we are talking about svn and our build process. This is not really a subject for a GSIP;
Well, me, Justin and Brent were of a different advice.
This is strategic from the pov of developing, and since it requires
a svn reorganization, it's critical as well.
Different point of views I guess
Cheers
Andrea
GSIP 11 actually is kind of orthogonal to those two questions. It's more about fixing a bit of a mess with how we store data dirs, and getting that in line with how data dirs originally were.
Running with no data dir is definitely a problem, but one that should be solved independently of this. Clustering is definitely a 'next' type question, and the baseline should be fixed first...
Jody Garnett wrote:
Thinking ... you guys are moving too quickly for me these days. I think I need to spend some time with before and after architecture pictures (I hate design discussion in the small with consequenes in the large).
So let me define the large:
- how do I run with no data directory
- how do I cluster the resulting GeoServerJody
Hi all,
following up the data dir handling issues me, Brent
and Justin had a quick chat and I think we have a
compelling proposal, which has been distilled in:
http://docs.codehaus.org/display/GEOS/GSIP+11+-+Data+configuration+handlingHopefully we'll be able to vote it during the next
Geoserver meeting.
Feedback welcomed here, on the ml.Cheers
Andrea-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:1003,45b9011c81901804284693!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
+1 for #2
Brent Owens
(The Open Planning Project)
Justin Deoliveira wrote:
Hmm, fair enough. I guess I thought that config directories would be something that cut across geoserver versions and branches. In that case I would prefer either of the following
1.
svn.codehaus.org/geoserver
+ trunk
+ branches
+ tags
+ config
+ trunk
+ branches
+ tagsOr
2.
svn.codehaus.org/geoserver
+ trunk
+ geoserver
+ config
+ branches
+ tags
+ configI guess #2 is more or less the original proposal.
-Justin
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Comment attached. Will past in here for discussion:
I would like to keep the svn layout as is, as it is the standard way to layout an svn repository. Instead just create another directory under the root of the repository called "config". So repo layout looks like:
svn.codehaus.org/geoserver
+ trunk
+ branches
+ tags
+ config
+ release
+ minimal
Ah sorry, I misread your mail (it's getting late here...)
How would you handle branches this way?
The config is something that's related to the geoserver
version you're playing with.
For example, config dirs for 1.5.x are incompatible with 1.4.x
and the opposite is (sadly) true as well (GEoserver is not
happy that there are no wcs elements in the services.xml
afaik).Cheers
Andrea-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:1004,45b8fd8475021460912952!
yup, #2 looks better
Gabriel
On Thursday 25 January 2007 20:29, Brent Owens wrote:
+1 for #2
Brent Owens
(The Open Planning Project)Justin Deoliveira wrote:
> Hmm, fair enough. I guess I thought that config directories would be
> something that cut across geoserver versions and branches. In that case
> I would prefer either of the following
>
> 1.
>
> svn.codehaus.org/geoserver
> + trunk
> + branches
> + tags
> + config
> + trunk
> + branches
> + tags
>
> Or
>
> 2.
>
> svn.codehaus.org/geoserver
> + trunk
> + geoserver
> + config
> + branches
> + tags
> + config
>
> I guess #2 is more or less the original proposal.
>
> -Justin
>
> Andrea Aime wrote:
>> Justin Deoliveira ha scritto:
>>> Comment attached. Will past in here for discussion:
>>>
>>> I would like to keep the svn layout as is, as it is the standard way to
>>> layout an svn repository. Instead just create another directory under
>>> the root of the repository called "config". So repo layout looks like:
>>>
>>> svn.codehaus.org/geoserver
>>> + trunk
>>> + branches
>>> + tags
>>> + config
>>> + release
>>> + minimal
>>
>> Ah sorry, I misread your mail (it's getting late here...)
>> How would you handle branches this way?
>> The config is something that's related to the geoserver
>> version you're playing with.
>> For example, config dirs for 1.5.x are incompatible with 1.4.x
>> and the opposite is (sadly) true as well (GEoserver is not
>> happy that there are no wcs elements in the services.xml
>> afaik).
>>
>> Cheers
>> Andrea
>>
>> ------------------------------------------------------------------------
>>- Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share
>> your opinions on IT & business topics through brief surveys - and earn
>> cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
>>V _______________________________________________
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>> !DSPAM:1004,45b8fd8475021460912952!-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Gabriel Roldán (groldan@anonymised.com)
Axios Engineering (http://www.axios.es)
Tel. +34 944 41 63 84
Fax. +34 944 41 64 90
I'm struggling to work out if there is any agreement on what os being voted on here...
Here's another couple or cases to consider IMHO, if someone can explain just how things will work in these cases I'm happy:
1) I have two versions of geoserver, running 50 different Feature Types. lets say the config is incompatible for 3 or these between version X and version Y - I want to load config 1 for the 47 and have version X load the 3 specific ones
2) I have two instances of geoserver (production and test) running 50 FTypes... I want to modify one FeatureType in the test version, and deploy it for a test period.
3) I have a series of configs for testing various paerts of the system, and I want to perform regression testing for each new version of geoserver I build, whilst keeping several previous versions running unchanged against one or more of these configs. (erg version X against Config A for one client, version Y agaisnt config B for another) - this seems to be the common requirement for developers delivering real systems,
distrubuting source code (sample configs) is one issue, the ability to actually manage configs (peicemeal loading) from multiple sources is another. I'm not sure what the implications are for this proposal - is some sort of default/override implied by having config in both the branch tree and the svn root?
Rob a
Chris Holmes wrote:
GSIP 11 actually is kind of orthogonal to those two questions. It's more about fixing a bit of a mess with how we store data dirs, and getting that in line with how data dirs originally were.
Running with no data dir is definitely a problem, but one that should be solved independently of this. Clustering is definitely a 'next' type question, and the baseline should be fixed first...
Jody Garnett wrote:
Thinking ... you guys are moving too quickly for me these days. I think I need to spend some time with before and after architecture pictures (I hate design discussion in the small with consequenes in the large).
So let me define the large:
- how do I run with no data directory
- how do I cluster the resulting GeoServerJody
Hi all,
following up the data dir handling issues me, Brent
and Justin had a quick chat and I think we have a
compelling proposal, which has been distilled in:
http://docs.codehaus.org/display/GEOS/GSIP+11+-+Data+configuration+handlingHopefully we'll be able to vote it during the next
Geoserver meeting.
Feedback welcomed here, on the ml.Cheers
Andrea-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
-------------------------------------------------------------------------Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:1003,45b9011c81901804284693!
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
------------------------------------------------------------------------_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Rob Atkinson ha scritto:
I'm struggling to work out if there is any agreement on what os being voted on here...
Here's another couple or cases to consider IMHO, if someone can explain just how things will work in these cases I'm happy:
1) I have two versions of geoserver, running 50 different Feature Types. lets say the config is incompatible for 3 or these between version X and version Y - I want to load config 1 for the 47 and have version X load the 3 specific ones
2) I have two instances of geoserver (production and test) running 50 FTypes... I want to modify one FeatureType in the test version, and deploy it for a test period.
3) I have a series of configs for testing various paerts of the system, and I want to perform regression testing for each new version of geoserver I build, whilst keeping several previous versions running unchanged against one or more of these configs. (erg version X against Config A for one client, version Y agaisnt config B for another) - this seems to be the common requirement for developers delivering real systems,
distrubuting source code (sample configs) is one issue, the ability to actually manage configs (peicemeal loading) from multiple sources is another. I'm not sure what the implications are for this proposal - is some sort of default/override implied by having config in both the branch tree and the svn root?
This is just a way to fix how we manage the _development and release_
process. We are not touching in any way the config code and its
capabilities.
It's just that the current way we handle the data dirs used for
release and testing is hard to mantain.
Jody and Rob, your points are well noted and appreciated, but these
comments are good for GSIP 8 and GSIP 9. I'm going to start a thread
for each so that we can get better organised with comments.
Cheers
Andrea
Sounds like there is good agreement on this. Just a note can we give people a "get out of the pool" warning before anyone goes ahead and does this. Thanks.
-Justin
Andrea Aime wrote:
Chris Holmes ha scritto:
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Comment attached. Will past in here for discussion:
I would like to keep the svn layout as is, as it is the standard way to layout an svn repository. Instead just create another directory under the root of the repository called "config". So repo layout looks like:
svn.codehaus.org/geoserver
+ trunk
+ branches
+ tags
+ config
+ release
+ minimalAh sorry, I misread your mail (it's getting late here...)
How would you handle branches this way?
The config is something that's related to the geoserver
version you're playing with.
For example, config dirs for 1.5.x are incompatible with 1.4.x
and the opposite is (sadly) true as well (GEoserver is not
happy that there are no wcs elements in the services.xml
afaik).That's bad. Is there any way we can get that to work?
Don't know at the moment, it all boils do to have the config
system handle optional elements and provide defaults.
Opened http://jira.codehaus.org/browse/GEOS-877 to handle this.
Cheers
AndreaPS: I should have opened this before... too many things going on,
I do loose bits here and there!DSPAM:1004,45b8ffa979462095110867!
--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org
Justin Deoliveira ha scritto:
Sounds like there is good agreement on this. Just a note can we give people a "get out of the pool" warning before anyone goes ahead and does this. Thanks.
Well since we had a GSIP for this, we need votes as well (the downside
of using a GSIP, as Jody warned). I prefer it like this anyways, since we're
going to change our directory tree layout.
So, so far we have positive votes from:
* aaime
* jdeolive
* bowens
We need another vote at least, and no negatives.
Cheers
Andrea
Honestly I like the zip files for configuration, but all you are right … if I need to change just a demo request which is an xml file of few bytes, I have to commit the zip file.
My only concern is, we used zip files to save space, now we are going back to a directory structure that stores the configuration directories uncopressed for every release. Personally I have no problems … so if it is good for you, go ahed.
Do you think it is too hard to preserve both ways (zip file and config dir)?
+1 for directory tree 2 proposed by Justin.
On 1/26/07, aaime <aaime@anonymised.com> wrote:
Justin Deoliveira ha scritto:
Sounds like there is good agreement on this. Just a note can we give
people a “get out of the pool” warning before anyone goes ahead and does
this. Thanks.Well since we had a GSIP for this, we need votes as well (the downside
of using a GSIP, as Jody warned). I prefer it like this anyways, since we’re
going to change our directory tree layout.So, so far we have positive votes from:
- aaime
- jdeolive
- bowens
We need another vote at least, and no negatives.
Cheers
Andrea
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net’s Techsay panel and you’ll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Eng. Alessio Fabiani
Vice President/CTO GeoSolutions
I should have been more clear on my previous post.
so +1 on option #2
PS: could we require a keyword on the subject when voting on a GSIP? something
like the one on this message: "vote on GSIP #NN". Would help to collect votes
or it's just that I get lost with ease.
Gabriel
On Friday 26 January 2007 09:12, aaime wrote:
Justin Deoliveira ha scritto:
> Sounds like there is good agreement on this. Just a note can we give
> people a "get out of the pool" warning before anyone goes ahead and does
> this. Thanks.Well since we had a GSIP for this, we need votes as well (the downside
of using a GSIP, as Jody warned). I prefer it like this anyways, since
we're going to change our directory tree layout.So, so far we have positive votes from:
* aaime
* jdeolive
* bowensWe need another vote at least, and no negatives.
Cheers
Andrea-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Gabriel Roldán (groldan@anonymised.com)
Axios Engineering (http://www.axios.es)
Tel. +34 944 41 63 84
Fax. +34 944 41 64 90