Refactoring - next steps

paul90 commented 11 years ago

Continuing the work started in #395 and #402.

I have recorded some thoughts, see code refactor in my fed wiki.

This will impact both the WardCunningham/wiki and WardCunningham/wiki-client repositories, as well as this one. As well as creating another 35(?) plug-in repositories (and npm packages).

N.B. If you comment by forking the fed wiki page, please provide a link to your fork here.

almereyda commented 11 years ago

As well as creating another 35(?) plug-in repositories (and npm packages).

:+1: I had to smile a little. :facepunch: :package:

almereyda commented 11 years ago

Another idea could be to finally create a #fedwiki GitHub Organization and move all concerning repos there.

WardCunningham commented 11 years ago

I've added some notes on CDN caching and fallback to @paul90 refactoring page: http://ward.fed.wiki.org/code-refactor-nov-2013.html

paul90 commented 10 years ago

The refactoring of the node version is now available, as an installable package. See paul90/wiki-exp.

This must still be considered a work in progress, the code for both the client and server is contained in the paul90/refactor branch of my forks of the wiki-client and wiki repositories.

Those wishing to try this new version can install it globally with npm:

$ npm install -g wiki-exp
$ wiki-exp --data ~/.wiki

N.B. A data path should be specified when starting the wiki, see WardCunningham/wiki#41.

almereyda commented 10 years ago

Great work! I was not really aware of the fact that this was a one person task.

Despite the last but one line carries a little typo : --data.

paul90 commented 10 years ago

Thanks, it didn't start out that way.

WardCunningham commented 10 years ago

Awesome work Paul. I fixed the typo, --data. I can't wait to try it.

WardCunningham commented 10 years ago

I've tried an install on my mac. It installed smoothly but won't start. Here is what I've tried.

$ wiki-exp
env: node\r: No such file or directory
$ wiki-exp --data ~/.wiki
env: node\r: No such file or directory
$ mkdir foo
$ wiki-exp --data foo
env: node\r: No such file or directory

paul90 commented 10 years ago

@WardCunningham can you try again - looks like a line ending issue. I have changed the line endings in bin/server.js and republished, which should resolve the problem.

WardCunningham commented 10 years ago

Updated to version 0.1.1. Works great. Thanks.

paul90 commented 10 years ago

That's good.

There are a few recent updates that have not yet made it across. I should get to them soon.

Ward Cunningham mailto:notifications@github.com 17 December 2013 16:08

Updated to version 0.1.1. Works great. Thanks.

— Reply to this email directly or view it on GitHub https://github.com/WardCunningham/Smallest-Federated-Wiki/issues/403#issuecomment-30763908.

paul90 commented 10 years ago

I think the following steps are needed to complete this.

Rather than creating new repositories, we will transfer the existing GitHub repositories to the fedwiki organization. GitHub will redirect to the new location - as long as we don't create a new repo with the same name - see https://github.com/blog/1508-repository-redirects-are-here, and https://help.github.com/articles/renaming-a-repository

I propose to create an issue in each repository with the relevant checklist.

For each wiki-plugin-*

[ ] Update package.json to include new repository and issues url
[ ] Update ReadMe.md
[ ] increment patch version
[ ] move to fedwiki org.
[ ] remove github wiki, if not already done.
[x] add ward as an owner of the package
[ ] republish to npm

for wiki-exp

[ ] review the documentation, and update
[ ] move to fedwiki org, as wiki, or to wiki-npm so like wiki-gem???

This will replace the existing wiki npm package, so need to get all the docs to reflect this, including details on how to contribute (both to the existing components, and also writing new plugins).

A few more steps that are needed once wiki and wiki-client steps are completed.

[ ] ensure package.json is updated, using npm rather than git to install the wiki-server and wiki-client packages, as well as new repository and issues url
[ ] publish to npm - this is the last step, as it will be published as wiki.

for wiki

[ ] review documentation, and update
[ ] move to fedwiki org, and rename as wiki-server
[ ] merge refactor branch into master
[ ] Update package.json to include new repository and issues url
[ ] publish to npm, as wiki-server

for wiki-client

[ ] review documentation, and update
[ ] move to fedwiki org
[ ] merge refactor branch into master
[ ] Update package.json to include new repository and issues url
[ ] publish to npm

Those who have forked the wiki and wiki-client repos on GitHub will need to update their upstream remote to use the new URL - though as we transfer/rename the repos they will get redirected. See https://help.github.com/articles/how-to-transfer-a-repository#redirects-and-git-remotes

How best to handle issues? As the many of the components (client and plugins) are used by both server implementations, I suggest that we central issues repository. The Smallest Federated Wiki repository would seem to be a good place.

WardCunningham commented 10 years ago

Wow. This is fantastic analysis. Thank you for the thorough step-by-step. I'm still studying it.

WardCunningham commented 10 years ago

Paul, I have granted you awesome power over the fedwiki organization so that you can create the repositories that you suggest. Please email me directly at ward@c2.com regarding rights and responsibilities related to this github mechanism. Thanks.

paul90 commented 10 years ago

A long list of referenced issues, one for each plug-in. So now just a matter of working through them all...

WardCunningham commented 10 years ago

You've set a good lead in the organization and documentation of each repo. I will go through each one and spruce up the documentation. A few of the older ones don't have wiki-readable pages. I'll fix that too.

almereyda commented 10 years ago

I inexpicably like what I'm seeing here. Finally the GitHub organization arrived.

As the issue descriptions propose indirectly and the domain is still available, I propose to register fedwiki.org. I could but wouldn't do so myself without acceptance of the core maintainers.

One could then run a new public Wikifarm there, building on the modularized Node version deferring from the new codebase emerging instead of the Rails stack. Until the code'd be ready, a simple pre-templated GitHub Pages landing page would suffice.

paul90 commented 10 years ago

All the plug-ins are now migrated over to the fedwiki organization. I have created an issue for those without an about page (but may have missed some), but documentation is best described as minimal.

WardCunningham commented 10 years ago

@almereyda -- I considered registering fedwiki.org but didn't. I had to remind myself that my goal was to "not own" federated wiki. With that in mind I would be pleased to see quality services provided by others and especially others with an anti-monopolistic bent.

If the fedwiki.org site were to suggest a strong association with our github repos then I would rather see it devoted to content related to those repos. Perhaps *.wiki-plugin-method.fedwiki.org would be many sites related to the ongoing development of the Method plugin, for example.

I'm not opposed to fedwiki.org or any other name variation being only loosely related to fedwiki. If you were to run a hosting service by any such name then you would be in a service business. I would hope that your service would do well by our name. But your relationship with your users would not extend to the volunteers contributing to fedwiki repos.

These are my thoughts of the last day or two. I hope they are clear enough to provide some guidance.

WardCunningham commented 10 years ago

(This text scraped from localhost. I post it here to expose my work in progress.)

This is a mechanically generated list of plugin document updates produced by comparing localhost/pages to clien/plugins/*/pages.

cd ~/farm/localhost/scripts
ruby docs.rb

Local About Pages

We look for local about pages and check them against plugin pages, if any.

About Parse Plugin.

Plugin Pages

We check each plugin for expected pages and local copies of any extant page.

About Bars Plugin. Needs about. Can't diff d3-bars.

About Calendar Plugin. Needs pages.

About Chart Plugin. Needs about.

About Efficiency Plugin. Needs about.

About Federatedwiki Plugin. Needs pages.

About Line Plugin. Needs about. Can't diff d3-line.

About Metabolism Plugin. Needs about.

About Parse Plugin. Needs pages.

About Scatter Plugin. Needs pages.

almereyda commented 10 years ago

If you were to run a hosting service by any such name then you would be in a service business. I would hope that your service would do well by our name. But your relationship with your users would not extend to the volunteers contributing to fedwiki repos.

I have to think further about this.

paul90 commented 10 years ago

Some very early notes on working with the new repositories, see http://wiki-paul90.rhcloud.com/working-with-the-refactored-node-code.html

As long as they make sense I would like to push on the final step...

paul90 commented 10 years ago

I should have said, those notes were written from the context that the refactor was complete, and the new/updated packages had all be published.

Thanks for your comments Ward. I have added some notes on using the 'wiki-exp' package, which grabs the refactored packages from github, until the updated 'wiki' and 'wiki-client' and the new 'wiki-server' packages are published.

WardCunningham commented 10 years ago

Ok, this makes sense. I was beginning to see that but was unsure what the next step for me would be.

We have lots of interlocking parts which will become much simpler when reorganized and fully scripted. I thought I'd try a from-scratch build just to see if it would work for me. I have several other copies of repos that are tied together with symbolic links. They make me more nervous than your changes. I'll be happy when I can leave them behind.

paul90 commented 10 years ago

Yesterday (25th Jan), Ward and myself worked through the final stages of getting the refactored code merged in, and the the associated npm modules published.

N.B. Before updating to use the latest version you should ensure you have a backup of your data directory. For those unsure where it is, when you run the wiki the parameters are displayed db points to where your pages are stored. If the directory pointed to by db is within a node_modules directory, if you don't backup your data it will be lost when you update the software.

For those who installed the npm version, using npm install -g wiki, simply need to run npm update -g wiki to upgrade to the new version.

The latest version will, by default, use ~/.wiki to store data. If your data has been lost in the upgrade, you will need to restore the data you backed-up above into this folder.

Those working with the git repos will find some notes over in fedwiki/wiki-node.

almereyda commented 10 years ago

claphands Am 26.01.2014 09:41 schrieb "Paul Rodwell" notifications@github.com:

Closed #403https://github.com/WardCunningham/Smallest-Federated-Wiki/issues/403 .

— Reply to this email directly or view it on GitHubhttps://github.com/WardCunningham/Smallest-Federated-Wiki/issues/403 .

WardCunningham / Smallest-Federated-Wiki