Having multiple parts of the book being split up and teams working on each part is a good idea in my opinion.
On 7/10/18, Bruce Dubbs <[email protected]> wrote: > 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 > -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
