Bill Page wrote: > > On 11/1/07, Waldek Hebisch wrote: > > > > Bill, I must admit that I have doubts concerning your migration > > tactic. > Waldek, I very much appreciate your taking the time to comment. I also > have doubts as I will explain below. But I would state my own goals > with respect to the migration somewhat differently: > > Primary goal 1: Support all versions/forks of Axiom at one website > Primary goal 2: Reduce the operating costs of the axiom-developer.org website > Secondary goal 1: update software > Secondary goal 2: migrate critical and selected content > > The first three goals are well served by re-installing the web > applications at another site. > Notice I do not mention either updating content or migrating users. > > > 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. > > > > I think we should be quite honest: There are very few users. Only > about 3 or 4 people have ever made any effort to actually use the web > site in the way it was intended - as a wiki, a community maintained > web site. I do not think there will be any problem convincing these > same people to continue to contribute to the new site. > > On the other hand, from the log statistics we can see that the Axiom > wiki website does have quite a large number of visits by people who > want only to read something about Axiom and is also very actively > crawled by the major search engines. From my point of view, I think > the partial content that I have already copied from the old site to > the new is sufficient to sustain this sort of use of the site. >
We are using different terminology here: for me people visiting the site are users. But I do not want discuss names here. For me important point of wiki is that content may be viewed by large number of visitors. And I belive that you want visitors to go to the new site. > > 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. > > I do not understand your comment about proofreading. You wrote about obsolete pages: to find out if a page is obsolete you need to read it. And my impression is that 100% obsolete pages are rare, rather part of a page is obsolete. So to eliminate obsolete pages and/or improve content you need proofreading. However below you explain that you just want mechanical copy... > I suspect that > probably my reference to cut-and-paste was not very clear and that you > probably are not very familiar with how the content of the Axiom is > created and maintained. Cut-and-paste is simple. It involves only a > few steps and the entire content of a page is transferred and > re-created in essential one step by clicking Save. > > Here is what I was hoping that you would do: > > When you looked at the AxiomContributions page and noticed that some > apparently useful content was missing you could have added it with > less than 30 seconds effort. For example in detail: > > 1) At the new site > > http://axiom-wiki.newsynthesis.org/AxiomContributions > > 2) You see > > [CommonDenominator for polynomials]? > > where you would like to see a link to this web page that existed on > the old site. > > 3) Click on the blue ? to begin (re-)creating the page. > > 4) Open the source for this page at the old site in a separate browser window > > http://wiki.axiom-developer.org/CommonDenominatorForPolynomials/src > > Notice /src at the end of the url and also the rule of removing > blanks and capitalizing the first letter of each word. > OK, so we have easy way to grab sources of all pages from the old site. > 5) Click Edit/Select All, Edit/Copy > > 6) Place the cursor in textbox in the page creation form and click > Edit/Paste to move the enter text of the page > > 7) Click the 'Create' button to render the new page. The link on the > AxiomContributions has been automatically updated. > This sound like work for Perl WW::Mechanize module. However, since you have direct access to the machine there should be easier way to submit pages. Note: I never used Mechanize module. Since I may need it for other purposes I am willing to try mass upload using it (assuming you have no easier way). > > 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". > > A wiki web site is never "complete". It is there to be changed, > updated and extended as time and motivation allow. > Yesterday contents page of the new site contained 74 positions, while contens page of old site had 913 positions -- that is large difference. > > 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. > > > > We can easily disable updates to the old site and direct the user to > the new site in the resulting error message page. > > > I would suggest to migrate content as much as possible in automatic > > way. > > Because of the change in the underlying software I do not know any > easy way to accomplish this sort of automatic migration for the Axiom > wiki site. I have already done as much automatic migration to the > Axiom portal site as possible using the ZSyncer tool. If you have some > ideas about how to do more automatic migration I would be very > interested in this. > I have no experience with Zwiki. But I would be very disappointed if Zwiki does not allow easy batch import from external source. > > Once the new site is fully functional I would made first > > stage of transition: > > I do not know what you mean by "fully functional" except if you refer > to content as we discussed above. Yes. > > More precisely: > > -- bugzilla is more restrictive when comes to edits, for example > > for normal users is append-only and does not allow unautorized > > changes to metadata (bug classification) > > Why do you think that is important? Do you expect such changes? > I think it is important to store _exactly_ the report: frequently little details does not mater, but sometimes give very important clue. I saw report which looked like somebody later edited them and reports were it was hard to distinguish what original reporter wrote and what later folks added. Which means that in _all_ cases there is danger that report was changed. I guess one can trace history of the page to check this, but it seems much simpler to use append-only mode. Concering metadata: there is a lot of bogus metadata in current IssueTracker. Part may be due to simple errors, but it seems that wandals frequently change metadata. I would say that anuthorised people have no business changing metadata and that maintaining metadata is less work than correctiong wrong changes. > > -- IssueTracker shows Axiom output as images which is unsearchable, > > does not work on text terminal and may hide some important > > information > > > > If desired Axiom output can be displayed in text form by including the > commands: > > )set output tex off > )set output algebra on > But that means that I would have to edit original report. Beside extra effort I would like to keep original report "as is". BTW: I _definitely_ prefer to store output of orignal report to recreating it on page change. Note that storing output avoids all tricky issues with changing versions. > But I do not understand why you would wish to use a "text terminal". > I _use_ "text terminal" -- that is just personal preference. > > I belive that common bug tracker for all Axiom forks would be good. > > In the past Tim said that he does not want FriCAS bugs in Axiom bug > > tracker, so FriCAS bug tracker was created. Certainly, common > > bug tracker make sense only if one can restrict view so that > > only bugs reported against given fork are visible. Technically, > > this should be not a problem... > > > > There are many good alternatives when it comes to bug tracking. For > example the Sage project is using the Trac system. > > http://trac.edgewall.org > > that includes it's own integrated wiki and interface to subversion. > > Do you think we should try to operate something like this as a common > bug tracker for all the Axiom versions/forks? > I have no experience with Trac. I really have no strong preference for specific software. I mentioned Bugzilla because it is known and works "good enough". I belive that changing IssueTracker in specific aspect I mentioned would not be very hard. So, now it is mostly question what other versions want. -- Waldek Hebisch [EMAIL PROTECTED] _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer