Difference between revisions of "Project Infrastructure Migration 2007"
(added some more....) |
(updates; especially for GRASS; added Automated Build/Smoke Test System) |
||
| Line 4: | Line 4: | ||
* Web pages | * Web pages | ||
| − | * Source Control | + | * Source Code Control |
* Bug/Issue Tracking | * Bug/Issue Tracking | ||
* Mailing lists / Forums | * Mailing lists / Forums | ||
| Line 14: | Line 14: | ||
Currently the members projects use: | Currently the members projects use: | ||
| − | * Wiki: OSSIM (Twiki), GeoTools (Confluence), MapBuilder (Confluence), Mapbender (Mediawiki) | + | * Wiki: OSSIM + GRASS (Twiki), GeoTools (Confluence), MapBuilder (Confluence), Mapbender (Mediawiki) |
* CMS: MapServer (Plone) | * CMS: MapServer (Plone) | ||
| − | * Static HTML: MapGuide | + | * Static HTML: MapGuide |
| − | * Doxygen (nightly generated HTML): GDAL | + | * PHP HTML: GRASS (but CMS forthcoming) |
| + | * Doxygen (nightly generated HTML): GDAL, GRASS (for programmer's manual) | ||
| − | CollabNet offers static HTML pages under SVN for web sites. This works fine for MapGuide | + | CollabNet offers static HTML pages under SVN for web sites. This works fine for MapGuide and GDAL. Not acceptable to MapServer nor GRASS. Migration is acceptable for Mapbender. Not sure about OSSIM, MapBuilder or GeoTools. |
| − | It would seem that a | + | It would seem that a Wiki solution for the web site should be offered. |
| − | For MapGuide | + | For MapGuide and GDAL migrating into the CollabNet website mechanism is no problem. Migrating out again (if needed) should also be straight forward. Migrating in and out for other projects would be moderately difficult due to all the reformatting needed. |
| − | == Source Control == | + | == Source Code Control == |
Some projects now using SVN, while others use CVS. | Some projects now using SVN, while others use CVS. | ||
| Line 33: | Line 34: | ||
Migrating in should be quite easy. The main downside is that all existing committer authentication will be lost, and will need to be resetup via the CollabNet infrastructure. | Migrating in should be quite easy. The main downside is that all existing committer authentication will be lost, and will need to be resetup via the CollabNet infrastructure. | ||
| − | Some projects currently use CVS (or SVN?) triggers to launch actions such as IRC (via CIA-bot) notifications, mailing list notifications and web site updates. Collabnet provides a mailing list for updates, but does not allow arbitrary commit hooks (as far as I (FW) know). | + | Will the CVS/SVN history be maintained when moving into/out of CollabNet? |
| + | |||
| + | Some projects currently use CVS (or SVN?) triggers to launch actions such as IRC (via CIA-bot) notifications, mailing list notifications and web site updates. Collabnet provides a mailing list for updates, but does not allow arbitrary commit hooks (as far as I (FW) know). The GRASS-CVS posts diff mails to a dedicated mailing list. | ||
CVS projects might want to take this opportunity to consider SVN which is superior technology. Howard Butler is knowledgable about how to do a CVS to SVN transition that preserves history. This would of course add some extra disruption for developers. | CVS projects might want to take this opportunity to consider SVN which is superior technology. Howard Butler is knowledgable about how to do a CVS to SVN transition that preserves history. This would of course add some extra disruption for developers. | ||
| Line 45: | Line 48: | ||
* Jira: GeoTools, MapBuilder | * Jira: GeoTools, MapBuilder | ||
* Wiki: Mapbender | * Wiki: Mapbender | ||
| − | * RT: GRASS | + | * RT: GRASS (Gforge planned) |
* CN Issue Tracker: MapGuider | * CN Issue Tracker: MapGuider | ||
| Line 60: | Line 63: | ||
* CN Mailing Lists: MapGuide | * CN Mailing Lists: MapGuide | ||
| − | CN offers a mailing list mechanism (ezmlm | + | CN offers a mailing list mechanism (ezmlm). It supports and easy mechanism for administrators to batch subscribe email addresses, so migrating existing lists to it is relative easy (though digest or other config options may be lost). It has a few quirks (no apparent way to limit messages by size, digest is by accumulated mail size rather than something like daily). But the mailing lists seem to work fine, and are integrated into the platform. Migration will require all subscribers updating their address books with a new email address. |
Migrating out it is easy to capture the subscriber lists, and setup a new external mailing list instance. It may involve a new email address again and will likely result in loss of email subscriber options. | Migrating out it is easy to capture the subscriber lists, and setup a new external mailing list instance. It may involve a new email address again and will likely result in loss of email subscriber options. | ||
| Line 84: | Line 87: | ||
Current projects: | Current projects: | ||
* No wiki: GDAL (want one!), MapServer (had one but wiki-spammed), MapGuide | * No wiki: GDAL (want one!), MapServer (had one but wiki-spammed), MapGuide | ||
| − | * Twiki: OSSIM | + | * Twiki: OSSIM, GRASS |
* Mediawiki: Mapbender | * Mediawiki: Mapbender | ||
* Confluence: GeoTools, MapBuilder | * Confluence: GeoTools, MapBuilder | ||
| Line 93: | Line 96: | ||
There would be no pressing need to migrate out as the wiki won't be dependent on collabnet. | There would be no pressing need to migrate out as the wiki won't be dependent on collabnet. | ||
| + | |||
| + | == Automated Build/Smoke Test System == | ||
| + | |||
| + | Current projects: | ||
| + | * GDAL: | ||
| + | * GeoTools: | ||
| + | * GRASS: script based build system for Linux, MacOSX, mingW; script/HTML based testsuite | ||
| + | * Mapbender: | ||
| + | * MapBuilder: | ||
| + | * MapGuide: | ||
| + | * MapServer: | ||
| + | * OSSIM: | ||
| + | |||
| + | Moving automated Build/Smoke Test Systems to CollabNet infrastructure could go along with a build farm. | ||
Revision as of 00:18, 29 March 2006
This document attempts to discuss the needs of projects currenting going through incubation. It attempts to address infrastructure needs, migration strategies to OSGeo servers, and migration strategies to mitigate disruption if OSGeo stops using CollabNet services.
Project Infrastructure Needs
- Web pages
- Source Code Control
- Bug/Issue Tracking
- Mailing lists / Forums
- Download server (http/ftp - binaries, source and data)
- Wiki
- Automated Build/Smoke Test System
Web Pages
Currently the members projects use:
- Wiki: OSSIM + GRASS (Twiki), GeoTools (Confluence), MapBuilder (Confluence), Mapbender (Mediawiki)
- CMS: MapServer (Plone)
- Static HTML: MapGuide
- PHP HTML: GRASS (but CMS forthcoming)
- Doxygen (nightly generated HTML): GDAL, GRASS (for programmer's manual)
CollabNet offers static HTML pages under SVN for web sites. This works fine for MapGuide and GDAL. Not acceptable to MapServer nor GRASS. Migration is acceptable for Mapbender. Not sure about OSSIM, MapBuilder or GeoTools.
It would seem that a Wiki solution for the web site should be offered.
For MapGuide and GDAL migrating into the CollabNet website mechanism is no problem. Migrating out again (if needed) should also be straight forward. Migrating in and out for other projects would be moderately difficult due to all the reformatting needed.
Source Code Control
Some projects now using SVN, while others use CVS.
CollabNet offers both.
Migrating in should be quite easy. The main downside is that all existing committer authentication will be lost, and will need to be resetup via the CollabNet infrastructure.
Will the CVS/SVN history be maintained when moving into/out of CollabNet?
Some projects currently use CVS (or SVN?) triggers to launch actions such as IRC (via CIA-bot) notifications, mailing list notifications and web site updates. Collabnet provides a mailing list for updates, but does not allow arbitrary commit hooks (as far as I (FW) know). The GRASS-CVS posts diff mails to a dedicated mailing list.
CVS projects might want to take this opportunity to consider SVN which is superior technology. Howard Butler is knowledgable about how to do a CVS to SVN transition that preserves history. This would of course add some extra disruption for developers.
Migrating out of Collabnet SVN is pretty easy assuming Collabnet provides access to the raw SVN archive (which they have agreed to do). The main disruption would be related to user authentication and a new location. SVN is open source so there is no need to change to a new tool if migrating out.
Bug / Issue Tracking
Currently members projects use:
- Bugzilla: GDAL, MapServer, OSSIM
- Jira: GeoTools, MapBuilder
- Wiki: Mapbender
- RT: GRASS (Gforge planned)
- CN Issue Tracker: MapGuider
CollabNet offers an issue tracker with roughly comparible capabities to other bug trackers. (please note significant distinctions here) However, it is not clear that there is a clean way to migrate bugs from other systems to the CN issue tracker. Lacking this it seems unlikely the projects with substantial historical bug databases will be eager to migrate to the CN infrastructure.
Should any projects migrate to the CN issue tracker, it is also unclear that there is any way to migrate bugs out again should we drop CN support, though apparently CN does support an XML export of the database so hand crafting tools should be *possible* with some lossiness.
It would seem that migration to (and from) the CN bug tracker are going to be painful.
Mailing Lists / Forums
Currently member projects use:
- Mailman: GDAL, GRASS, OSSIM, MapBuilder, Mapbender, GeoTools, MapServer
- CN Mailing Lists: MapGuide
CN offers a mailing list mechanism (ezmlm). It supports and easy mechanism for administrators to batch subscribe email addresses, so migrating existing lists to it is relative easy (though digest or other config options may be lost). It has a few quirks (no apparent way to limit messages by size, digest is by accumulated mail size rather than something like daily). But the mailing lists seem to work fine, and are integrated into the platform. Migration will require all subscribers updating their address books with a new email address.
Migrating out it is easy to capture the subscriber lists, and setup a new external mailing list instance. It may involve a new email address again and will likely result in loss of email subscriber options.
Overall, there is not a high cost to migrating in or out of the CN mailing list architecture.
Download Server
Existing projects offer source, binary and data downloads through http and ftp.
Collabnet offers an http based download facility from from the "Documents and Files" area on the left nav bar. This seems roughly analygous to the download support in SourceForge, and is generally adequate for downloads. (are there any perceived problems?)
There may be a migration hassle for folks moving large amounts of existing files into CN but generally speaking migration to CN for downloads should be straightforward.
Migrating out should also be relatively easy. Just "wget" the files to another server or something similar.
One downside of CN is that it doesn't offer ftp download services, but it isn't at all obvious to me that this is important in 2006. (comments?)
The other issue that could arise is that sufficient popularity for OSGeo projects could push the limits of our CN bandwidth limit (not sure what it is) in which case we might need to move some big things to the telascience hosted servers.
Wiki
Current projects:
- No wiki: GDAL (want one!), MapServer (had one but wiki-spammed), MapGuide
- Twiki: OSSIM, GRASS
- Mediawiki: Mapbender
- Confluence: GeoTools, MapBuilder
Currently CN does not offer a wiki. Arnulf has kindly hosted a mediawiki instance for OSGeo.
It isn't clear if there are benefits to moving into a common wiki for projects. We could likely host mediawiki instances for each project at telascience if needed.
There would be no pressing need to migrate out as the wiki won't be dependent on collabnet.
Automated Build/Smoke Test System
Current projects:
- GDAL:
- GeoTools:
- GRASS: script based build system for Linux, MacOSX, mingW; script/HTML based testsuite
- Mapbender:
- MapBuilder:
- MapGuide:
- MapServer:
- OSSIM:
Moving automated Build/Smoke Test Systems to CollabNet infrastructure could go along with a build farm.