URI Migration Map

This is an attempt to model what will need to move from where to where and knowledge of the previous location be preserved. It is intended to help move content from the current site and this wiki into the prototype new osgeo website. It's also intended to help facilitate the migration of other project documentation and source repository onto nice osgeo-hosted facilities.

A lot of this right now is braindump notes, in future there will be actual RDF models representing what moves where.

OSGeo websites

www.osgeo

Ideally the prototype would replace this - prospective new osgeo website

All the committees should consider moving their homepages here - e.g. www.osgeo.org/education or www.osgeo.org/visibility . Migration of lists onto new simplified facilities will happen later, see below.

See also a quick Google Sitemap of the current site : https://www.osgeo.org/sitemap.xml

Issues

• If this is actually going to happen by F0SS4G we need to make a definite schedule for the Drupal Portal and stick to it.
• There may be mailing lists underneath www. that need to be moved.
• Cool URLs don't change - we need to provide a map of what already existed that can provide a collection of RewriteRules - see google sitemap above
• This needs a URL plan that people really stick to. It's maybe going to be easiest / quickest to document this in the wiki - or could make a quick cgi to do it ...

[projectname].osgeo

As an option sites can have a custom drupal theme which gets some of the news from the main site and uses the same database. It has connections in to a download area, source view area, demo area

trac/svn.osgeo

There should be an installation of trac - import project history into SVN. URLs go /[projectname] or /[activity] . It would be good to get a trac of the website development activity in place. This would not use trac's wiki at all.

lists.osgeo

Mailing lists would be a lot easier to manage if they were all in one subdomain. We use mailman, get list content import from previous facilities, look for a better archive frontend than pipermail with proper search across the whole collection. We may not wish to seek to preserve the URLs of previous mail archives though a perl script would do it if deemed necessary.

Issues

• Right now the mailing lists are on a whole world of different subdomains which we'd probably want to go away or change function. Mailing Lists gives an idea of what's actually being used.