On 07/10/2018 07:46 AM, Douglas R. Reno wrote:
I'm of the opinion that we should do one more release of the book as it
is and then discuss things after that. I'm willing to put in as much
time as needs to be put in to keep everything in the book that is
currently in there, for one more release at minimum. Consistency is the
thing that is the most important to me, and one more release would also
give people who use LFS in production the time to adapt their systems
for the new changes. It's way too big of a change to make 1-2 months
before release, this should really be done after.
I've got permission from those around me to contribute as much time as
necessary. I'll test both sysvinit and systemd before release if
necessary as well.
I'm saying this as a person who used to work for a company (not to be
named publicly) that used LFS in production on factory and CNC systems.
I'm also saying this as one who uses it in PROD for weather modeling
systems. We need more than 1-2 months for a huge structure change.
I appreciate that.
I did some playing around with the source yesterday and found that
Docbook supports multiple books in one system. The example from Docbook is:
<set><title>The Perl Series</title>
<setinfo>
<corpauthor>O'Reilly & Associates, Inc.</corpauthor>
</setinfo>
<book><title>Learning Perl</title>
<chapter><title>...</title><para>...</para></chapter>
</book>
<book><title>Programming Perl</title>
<chapter><title>...</title><para>...</para></chapter>
</book>
<book><title>Advanced Perl Programming</title>
<chapter><title>...</title><para>...</para></chapter>
</book>
</set>
I tried that and it works.
On the other hand, we might be able to just reorganize the BLFS book
into two major sections. Basic and Advanced (or some other titles).
The point is that we need to be able to release BLFS with some packages
not being the latest versions and not necessarily tested with the
latest LFS (or just remove those packages).
What we have been doing is a package freeze about two weeks prior to a
scheduled release. For me, that means spending an estimated 100+ hours
in that two weeks building against the new LFS and testing builds and
limited functionality. I just can't do that any more.
In addition, the above assumes that the development version of BLFS is
reasonably current and I have most of the scripts needed for the current
packages in the development version of the book. Right now there are 84
outstanding tickets even though Tim and Thomas and Ken have been doing
updates. Even if we magically got up-to-date today, there would
probably be another 100 or so needed updates before the scheduled
package freeze in mid-August.
What I am looking for is a long term solution so we can continue to put
out a solid product within our constraints.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
