Future of LFS
gerard at linuxfromscratch.org
Sun May 18 15:05:52 PDT 2008
> It may not be the right tool for _you_. :) But it may very well be the
As long as a GUI tool can produce the code we currently have (it may be
complex but that's in part due the syntax of DocBook) then it would be a
If the tool forces a simplification and lessening of tags and XML
constructs in use, whose end result mean final rendering in a lesser
format or having to update the same information in multiple locations,
then it may not be the right tool anymore.
For instance, the entities we use aren't always fun to update, but we do
so in order to update a piece of text once that gets used in the book
more than once (URL components, version numbers, etc). Those mechanisms
need to stay in place to avoid having to do (and subsequently forget to
do) double work.
If this doesn't make sense let me know and I'll elaborate.
> right tool for someone else, and make it easier for new contributors
> to add changes to the book.
New contributors shouldn't be adding anything to the book without it
first being verified, tested and finally edited.
New contributors should submit proposals and proposed changes to the
list. The book will not become a free-for-all style ala Wikipedia where
that kind of style is welcomed and even useful.
That kind of "free for all" style should be part of the wiki. The final
actual official book we produce has to undergo quality control.
After something new has been submitted and agreed by the project's
developers it would be a good addition, then we can worry about
XML-ifying that data. Unless the contributer has figured out the XML
already and we can use that as a base to save some time.
If you look at most every other project - John Doe doesn't just modify a
project by having his (random) changes and wishes included. They are
decided upon by the developers. This is not a bad thing.
If somebody wants to become an LFS developer (what we call a book editor
among other things), then they need to learn our code, comply with those
standards and contribute for a while.
Just like in any other project, their developers need to be able to
program in that project's chosen programming language and style.
I realize the LFS project isn't the same but *some* of those basic
principles still apply.
> draws it up and is able to convey the right ideas, they've done 80-90%
That's what I was getting at. That person who does 90% of the work can
easily do so and submit the text to lfs-dev list or write it up on a
That doesn't *have* to mean this person should also commit to SVN at
will which ends up in the "read online" links. If there is indeed an
issue with style, English language barriers and technical skillset
issues, then that initial write up should be edited by a book editor
before it appears in the book itself.
To me it sounds like you're saying anybody should or would be able to
commit anything they desire to the book's content.
That discussion aside I do agree the XML code as it currently stands is
cumbersome and it would benefit from a change of some sort. The purpose
of that change is to make it easier for project developers to main the
project. Not to make it easier for random people to start adding content
Wiki pages don't count. Those areas would be great for users to work in,
have other people including us developers comment to it, and further
enhance. Then when the time is right, we can grab that stuff and put it
into the LFS book itself.
At the end of the day if somebody doesn't understand how to use <para>
tags (which are the most frequently used ones), then a final editor can
just add those during the inclusion of that person's changes. And
include other tags that make sense.
More information about the lfs-dev