[mythtv-users] Mailing list and a Wiki... and a dessert topping
David
myth at dgreaves.com
Tue May 18 09:39:04 EDT 2004
Peter Valdemar Morch wrote:
> David myth-at-dgreaves.com |Lists| wrote:
>
>>> You might even start by importing the current documentation to your
>>> wiki.
>>
>>
>> It's a good idea - I though about it quite a bit - we'd need to keep
>> in sync and it's too hard for now.
>
>
> Now there is a way-cool idea.
> LinuxDoc/SGML can generate output in a variety of formats, and surely
> WikiMarkup could be one of these formats. As a starting point for the
> docs.
This won't be a one-off will it. (see later)
> Seperated into different pages, just like the HTML docs. When a CVS
> update occurs, this is done by patching as in:
>
> diff -ur previousOfficialWikiMarkup/ currentWiki/ > userContribs.diffs
> mv currentWiki/ currentWiki.old
> mv officialWikiMarkup currentWiki
> cd currentWiki
> patch -p1 ../userContribs.diff
>
> At any point,
>
> diff -ur officialWikiMarkup currentWiki
>
> is the user contribution to the documentation...
>
> I like the idea. A lot. Some work, naturally, especially when there
> are merge conflicts (append the user contributed part of such
> conflicts to PageName/Conflicts?) But it would be *very* slick! And
> actually useful for many other projets as a
> keep-documentation-up-to-date thing. I love this idea!!
That does sound very interesting...
> Does anybody know how tricky it is to do the LinuxDoc->WikiMarkup
> translation. Something about XSLT, right? I'll try to look into that.
> As far as I can see, this is the only really tricky part of the whole
> thing.
And in reverse... I was thinking of taking Moin's Wikiformat -> XML ->
Linuxdoc (actually DocBook but I was wrong)
I suspect you want to let MoinMoin do that. It's not easy. Take it's
parsed output in XML rather than HTML and XSLT that.
BTW, append "?action=format&mimetype=text/xml" to a Wiki page and you
get xml.
eg:
http://www.mythtv.info/moin.cgi/HardWare_2fVideoCaptureCards_2fPvR350?action=format&mimetype=text/xml
Are you suggesting a process like:
* change to official docs (be that a release or a CVS commit)
* convert previous and current to WikiFormat to get patch
* apply patch to affected wiki page
What about this:
I was thinking of making the generated WikiPage immutable. Create a sub
page with comments. The sub page could have chunks reproduced and edited
ready to form a patch. This gets around the collision problem and:
* makes .org the master for the parent page
* allows the sub page to contain Wiki links to potentially O/T areas
(Hell, you could even use Moin's processing instructions to mark a chunk
from the page, tag it, wrap it as a patch and send it to the official
maintainer. Then if/when the patch comes in Moin could blat the tagged
bit as it would live in the parent.)
The process is then:
* change to official docs (be that a release or a CVS commit)
* convert current to WikiFormat
* replace affected wiki page - leaving sub page in place
* remove redundant info from the subpage
Makes me think: why not have two subpages? One for 'info' one for 'patches'?
Like this:
http://www.mythtv.info/moin.cgi/OfficialFaq_2fFAQ21_2e18
The process is then:
1 change to official docs (be that a release or a CVS commit)
2 convert current version to WikiFormat
3 replace affected wiki page - leaving sub pages in place
4 remove redundant info from the ProposedChanges subpage
Obviously 1 can be triggered in many ways (including current submit
patch process) - the Wiki way would be:
* make changes in /GeneralDiscussion - iterate and manage
* move changes to /ProposedChanges
* submit patch to docs (manual)
* if accepted goto 1
* if not accepted, create new WikiPage and put a link at the top of
GeneralDiscussion.
David
More information about the mythtv-users
mailing list