New year, new site, new wiki

Justin C. Sherrill justin at
Sat Jan 3 22:07:16 PST 2009

I hope you like text; I'm going to get all expository.

The Problem:

We have the website, and the wiki.  The wiki is easy to
update but messy.  The main website is ordered but not easy to update. 
Both have revision control, but the website's in Git and the wiki's in its
own internal 'bunch of numbered files' system.

I don't like MoinMoin, and I think nobody really cares for visual aspects
of the existing DragonFly site.  (The 'salad')  Having two sites to
maintain means they get unequal amounts of attention.


Merging the wiki and the website is a clear way to fix this, but there's
restrictions.  Many wikis, including the most popular, Wikipedia, work
with PHP.  Matt doesn't want to run that on a public server, and I can't
say as I totally disagree.  Given how messy wikis can be, people don't
like the idea of the whole site potentially becoming that untidy.

Knowing that if I'm going to complain, I had better come up with a
solution, I looked through a lot of wikis in the latter part of 2008, and
the option that looked the best without having to reinvent the wheel was

ikiwiki stores its files in a revision control system, like Git, and
generates static web pages from that.  It also includes a CGI that lets
people edit pages like a normal wiki, and will commit those changes back
to the repo.  It will also regenerate affected pages after a 'git push'. 
It takes normal HTML or Markdown or Textile.  So, we can add to the site
by editing/creating pages and committing, same as with the rest of the
DragonFly source, or via the web.

The Result:

I've converted the site and everything I could find in the wiki.  It
actually worked more nicely than I expected.

There's some old MoinMoin directives mixed into some pages that are easy
enough to clean up, and I didn't keep history, but I don't think that
matters.  A positive side effect is that I was able to get rid of a lot of
pages that were near-empty or merge content that was only separate for
historical reasons.  There's plenty more that can be done - however, it's
a lot easier with this for anyone to update and change where needed.

In theory, we could even add in the man pages and/or the mail archive,
because of how ikiwiki pulls from a repository.  The website portion is
locked, so nobody can edit it from the web.  The documentation pages under
doc/ are all editable.  Otherwise, it requires commit access to change it
via git.

I'm running ikiwiki 2.66, from pkgsrc, here - version 3.0 just came out,
but the way I've been setting this up, all the existing data is
compatible.  The transition should be easy.  I think since it's a Git
repo, it can be shifted over to a system (assuming we
have agreement on doing it) with little effort.

If there's some data on the wiki that I missed, tell me.  I deliberately
skipped a few things, like the release-specific download pages, since I
wasn't sure if those would be valuable.

So, reactions?  I think I've covered every issue I've heard from other
people, but I'm sure there's something I didn't think of or hear about.

More information about the Kernel mailing list