genericmailli...@gmail.com wrote:
> 
> You don't need to change the book number just make the changes in 
> the book. On the page where the people will download the book just 
> warn them to check there for the newest version. This is what other 
> major open source developers do. Why do you want to make it 
> complicated. You are not empressing any one by doing it the old 
> hard way.

What you propose sounds like a major train wreck type disaster
in version control.

> To deliberately limit yourself in that manner with a live flowing 
> electronic document is just foolish. Why limit your flow of 
> communication by following the traditions of an old technology that 
> does not have a better choice?

The better choice is to have consistency and good version control.
The book itself is part of an entire supported released system,
not just a bunch of bits on a disc drive.

You apparently have little experience with maintaining something
like the enormous project LFS is, and the effort it takes to keep
everything in sync in a project like LFS. What, on the surface,
seems like stubborn reluctance to do things "the obviously better
way" involves very much more than you imagine. The LFS book is
used to create scripts, and requires, as another mentioned,
creating directories, ensuring that no other defects were introduced,
doing regression testing, etc., in order to make sure that everything
is consistent.

Having an errata page available seems like the perfect solution
to sequestering the frequently changing parts from the parts
which require careful analysis and quality checks. If the errata
page gets broken, then it just gets fixed, and we go on. When
the next release comes out, and we think we have enough changes
to do a full rebuild and regression check, we incorporate all
the known errata into the newly released version. It makes
perfect sense to anyone who has to maintain and support a large
project. The documentation is part of the revision controlled
released product, not an afterthought on the web, which may
or may not match the software package as a whole anymore, due
to "fixes".

This sort of thing is standard practice with all major projects,
and has nothing to do with the medium in which the components
get realized. It has everything to do with quality assurance
and version control.

Also, as pointed out, if one actually reads the book (interesting
thought, actually reading it, as opposed to searching for interesting
bits and then trying them out), one notices the errata notice right
there. I had no problem finding it.

True, even people reading things don't always notice what
they just read, and may forget that they saw it. However,
a quick recheck, or even an e-mail here, will soon put one
on the right track.

I trow you will not forget about the errata page in future,
and neither will anyone else who has read this thread. Of
course, in a few months, someone else will probably overlook
the pointer in the book.

Life goes on.

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page

Reply via email to