Bill Page wrote:
Dear Axiom Users and Developers;
Earlier in October Tim Daly asked me if I would be able to move the Axiom
wiki:
http://wiki.axiom-developer.org
and the Axiom portal:
http://portal.axiom-developer.org
web applications to a new server.
In spite of this and in view of Tim's desire to complete the move as
soon as possible, I would like to invite everyone to begin using the
new sites now. They can be found at:
http://axiom-wiki.newsynthesis.org
and
http://axiom-portal.newsynthesis.org
So I would like to encourage everyone who cares about Axiom (and/or
it's forks) and who is interested in wiki and portal support for these
projects to help with testing and re-populating the new sites as soon
as possible. After three years of operation of the Axiom wiki there
are a fairly large number of out-dated, poorly organized and possibly
irrelevant pages which probably should not be simply copied over to
the new site. I would be very very happy if some other Axiom users and
developers would agree to assist with this shifting and
re-organizing effort. Copying missing content between the sites can be
easily done by cutting-and-pasting the text from the 'edit' of the old
site to the corresponding 'edit' page of the new site.
Bill, I must admit that I have doubts concerning your migration
tactic. AFAU there are two goals:
1) Primary goal: migrate content and users from the old site
to the new site.
2) Secondary goal: update software and the content.
As you wrote: Axiom wiki is a comunity site, so migrating users
to the new site is crucial. But to migrate users it is
essential to migrate content. I took quick look at the new site
and I see that a large part (most??) of content is missing
-- for example most links on AxiomContributions page does not work
and many positions from the page on the old site are missing.
IIUC you propose to transfer rest of the content via cutting-and-pasting
from the old site. I think this is problematic: without proofreading
almost any automatic procedure will work better. You probably hope
that volunteers will proofread the content while copying. However,
it seems that creating current content took about 3 years. I would
expect that proofreading the site will take month or two and
proofreaders will be slowed down by the need to copy things --
I am not saying that proofreading itself takes a lot of time,
but simply that our volunteers are in general busy, and can spend
only a short time doing this.
During that time the new site will be more or less broken, so many
users will try to use the old site -- since only old site will
be complete. Similarly links will continue to point to the old
site. Another problem is that users may come to the old place and
add content there -- migrating additions will cause extra trouble.
I would suggest to migrate content as much as possible in automatic
way. Once the new site is fully functional I would made first
stage of transition:
-- put prominent notice about new site on the front page of
the old site
-- change old site to read-only and display notice about new
site on any attempt to edit
-- redirect all links to the new site.
In the next stage (two weeks or maybe month later) I would replace
all pages on the old site by a notice about move and link to
the corresponding page on the new site. I would handle updates
to the content separately.
Rationalle: without proper action users will continue to come
to the old site: it shows in search engines, it is in bookmarks,
there are links to it. The first stage is intended to shift
critical mass of links and users to the new site. To avoid loosing
users old site should be operational. Making old site read-only
should avoid problems with synchronization. Redirecting links
should help with search engines and bookmarks -- search engines
should notice new site, new bookmarks to links will point to
the new site.
Concerning update of content: the move may cause some loss of
users. Operating both sites in paralell is intended to minimize
user loss. However, it is essential that new site is fully
operational -- otherwise users will go to the old site or we may
loose them. IMHO trying to update content during migration
slows down migration and causes extra work.
The most serious missing component at the new Axiom wiki site is the
existing database of IssueTracker reports. I have tried unsuccessfully
to copy to the old database to the new server. In any case it is also
true that a number of these reports may be obsolete or may not apply
equally to all of the Axiom projects. Also some of the Axiom projects
(forks) have their own way of tracking problems, e.g. OpenAxiom simply
uses SourceForge. So I am open to suggestions on how to proceed with
this transferring this information (and/or comments about whether this
is really necessary or not).
FriCAS also has a bug tracker at SourceForge. As a person
