genericmailli...@gmail.com wrote:
[...]
> Why do so many computer geeks want to make things complicated?
I am not a member of the LFS support, development, or maintenance
teams and efforts, and do not speak for any of them. I speak
only for myself. I will allow that I am what you probably
refer to as a "computer geek", since I've been team leader for
projects involving as many as twenty software engineers and
lasting for periods of up to two years for initial development,
and participated in projects involving hundreds of engineers
for even longer periods. I wrote my first computer program
in 1967 or so.
You are displaying complete ignorance of what the terms
"Quality Control" and "Version Control" mean. I suggest that
you study a little bit.
The reason we want to do things the way you call "complicated"
is because it vastly uncomplicates a number of other things,
of which you seem to be completely ignorant.
Experience with doing things the "simple" way has convinced
those of us who actually have maintained large projects that
it is much more complicated than what you perceive to be
the "complicated" way.
"Everything should be made as simple as possible, and no
simpler." A.Einstein
You want to make things simpler than is possible. It's like
squeezing a balloon. If you squeeze out complexity in one area,
it bulges into others. Supporting a static product, with
static, known defects, each of which has a static solution
is much simpler than supporting a non controlled fluid
product which has no static defects, since nothing about it
is static. A static product has, by its nature, a fixed finite
number of (in principle) knowable and fixable defects. A fluid
product, by its nature, has no finite limit to the number and
kinds of defects it possesses.
I think the comment that the type of volatility you seem
to desire is better served by the "dev" non version of the
book, software, and project, is spot on, and perhaps you should get
your stuff there. Be aware, however, that some of that stuff
is likely broken in places, the procedures described may not
actually work as written, and support may be almost non existent,
and may just get a response like "Yeah, we know that's broken;
we expect to have it working an a couple of days."
In fact, it is what you would get from LFS as the final product
if they did things the way you suggest.
Until you've walked a mile or so in the support team's
moccasins, I suggest you not criticize their careful
decisions based upon their painful experiences trying to
do things the way that seems correct to you, and seeing
them fail.
In a project like this, coordination of effort is vital,
and can be achieved, as far as my experience tells me,
only through fixed static releases. Otherwise the support
and maintenance teams have an impossible task. Large projects
need careful separation and coordination of development,
support, and maintenance. Sometimes the people can wear
two or even all three of the hats, but the efforts need
to be distinct. The errata sheets are a part of the
maintenance effort, while the book itself is part of the
support team's stuff (though the support team probably
makes recommendations for the maintenance effort).
You are suggesting conflating distinct efforts, which
may be carried out by different teams of people. Doing
as you suggest also, in a project like this, would
likely involve the development team.
That's my $0.02 USD worth.
Since this has now gotten seriously OT for LFS, I think I'll
not respond to this thread any further here. Let's take this
off list or to /dev/null.
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
