Subject: Exported From Confluence
Content-Type: text/html; charset=UTF-8
Move to another Server
Move to another Server
This page represents the current plan; for discussion p=
lease check the tracker link above.
Refractions Research has been kind enough to host our svn since aro=
und 2004. At the time GeoTools was hosted on Source Forge and everyone was =
loosing a day a week due to Source Forge having growing pains.
In the last three months the Refractions server has been "under att=
ack". It looks like a script starts up; downloads every link - and get=
s bored waiting for some of the larger files - and tries again! Now servers=
are pretty good at handling this kind of abuse; but in this case the scrip=
t is poorly written and does not complete the HTTP protocol. In linux the o=
perating system handles a few stages of these exchanges and is stuck waitin=
g for a "CLOSE" message that never arrives; the Kernal has been c=
ompiled with a 2 minuet time out ... leaving us stuck.
We have three options available to us - we can consider the following op=
- Ask Refractions to upgrade there server (scrub it down; build a new ker=
nal with a shorter timeout; etc...). Currently there is not enough sys admi=
n time (because everyone is working hard for customers) to make this happen=
Move to CodeHaus - this has the advantage of single sign on with our wiki;=
and the ability to make use of their maven repository. The GeoServer proje=
ct is making use of both these facilities so we can ask them if it is in fa=
ct a good idea. The CodeHaus servers are connected to the maven replication=
train - which will really resolve some of our distribution issues with http://lists.refractions.net/m2
- Move to OSGeo hardware - this has the advantage of branding.=
We would need to run our own svn server - and could consider running our o=
wn confluence as well.
- [~jive} I personally feel that OSGeo hardware has nice publicity - b=
ut the cost in time of running our own hardware is not worth it.
- Jody Garnett This p=
roblem is not specific to the GeoTools project, I will bring these options =
up in the uDig meeting on Thursday as well.
Please understand we are running a couple of days downtime a month; I wo=
uld rather spend two days up front to improve the situation (and thus be ab=
le to plan for it) then have my project deadlines in danger.
Voting for this proposal was carried out with the choice between OSGeo a=
nd CodeHaus hardware.
With this in mind the proposal is accepted with OSGEo hardware as the in=
tended location for the move.
This section is used to make sure your proposal is complete (did you=
remember documentation?) and has enough paid or volunteer time lined up to=
be a success
Moving svn repository to OSGeo:
- Email Paul Ramse=
y (who will apparently handle things?)
- Sign up developer list to OSGeo
- Confirm with checkout
- Update pom.xml files? Will not be needed if we can redirect svn.geot=
Moving maven repository:
- Update the pom.xml to refer to new locations (see BEFORE/AFTER below=
- Confirm build works
- Confirm deploy works
- Confirm assembly works
Updating the docs and communicating the change:
- Update the user guide links (mostly for sample code) Michael Bedward can help with=
- Update the developers guide svn checkout instructions Michael Bedward can help wit=
- Update GeoServer and uDig builds (they can actually do that at anyti=
me when they are ready)
<name>Web site for Maven reports</name>
<name>Refractions Research - Maven 2 repo</name>
Move to osgeo servers:
<name>Geotools Central Development Repository</name>
- Home SVN checkout instruction=
s need to be updated