Wiki Development Festival
peterph-lists at black-net.org
Sat Oct 18 15:22:17 PDT 2008
I wasn't following the list lately (as is obvious from my previous post
in this thread), so I'm definitely not knowing what exactly I'm talking
Jan Dvorak wrote:
> Answer these, please:
> * Do we want the book to be completely maintainable online, or are we
> comfortable enough with some source control system?
> * If Subversion (git?) is enough, do we want everything nicely (with colors
> and such) accessible online, or are we okay with static dumps?
> * Do we want automatic dumps, or are going to submit them when we want?
I would go for version control system only (not excluding the
possibility of a web interface for submits) and automatic static dumps
triggered on checkins (lower performance requirements, always
up-to-date, faster to implement). Considering the "Future format of the
book" thread (and the current one), "tagged" scripts might be an easy
and convenient way to achieve this. Special comments would be used for
marking start/end of parts in the HLFS scripts. These could be
pre-processed by awk/sh/perl/whatever script and thrown to a syntax
highligher (arbitrary if possible). However, note that this resembles
the old XML in many ways.
> * Do we want tools to create (or at least verify) builds, pages, patches..?
Sorry, I'm lost here again (feel free to point me to some older thread,
if there is one): what do you mean by "creating builds, pages"? Building
the Book which - as far as I understand - should be a collection of
scripts (sometimes only a text), patches and policy definitions for each
page of the Book (that is transforming scripts into html), or building a
HLFS system (which would be more of a job for the ALFS)?
> * Have the tools be online? If everything is, it's obvious, but if not?
Does it make sense to keep them from general public?
> * Do we want web interface to submit new things? Is e-mail not enough?
> * What source control system are we going to use, if we are not bringing it
> online? Subversion is there, but there are alternatives that simplifies
> collaboration a bit.
That would depend a lot on the next question. If more users are going to
do updates, or if non-trivial branching is expected, git *might* be
better choice (I'm certainly not an expert on this).
> * How many people out there are actually interested in working on the book
> and not only reading/following it?
More information about the hlfs-dev