Future of LFS

[Gerard Beekmans]

> 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 
tool, definitely.

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 
wiki page.

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 
more easily.

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.

Gerard