On Fri, 23 Aug 2019 at 09:22, Jean-Marc Pigeon via lfs-dev <[email protected]> wrote: > > Bonjour, > > English is not my native language, I'll try my best > to give|share some ideas about LFS to Akira and you(list), > so please bear with me. > On 08/22/2019 10:12 AM, Bruce Dubbs via lfs-dev wrote: > > On 8/22/19 3:35 AM, Akira Urushibata via lfs-dev wrote: > >> > >> I will talk about LFS on Saturday (Japan time) in an event for open > >> source developers. > >> > >> ... > >> > >> I will speak on the merits of LFS, how the build process works and > >> prerequisite skills. Because I think consider a major shortcoming of > >> the current LFS Book is failure to discuss project management, I plan > >> to make it clear that you need project management skills to succeed in > >> building a working system and tell the audience what those skills are. > >> .. >> > > There is need for "project management skill" and very good discipline to > have recurring success to build a consistent LFS (even more needed > with the bLFS part). Rebuilding from scratch over and over is a must.
As someone who has always tried to buiid LFS within the "More control and package management".approach, I actually feel that any need for the LFS Books to discuss "project management" is NOT a shortcoming of the Books. Everything you need to build a working system is there in the Books: you don't need anything else. Furthemore, LFS tries to list dependencies and installation order, even if there is a little "wiggle room" (usually depending on how one views the necessity of one or two of the packages) so again, there is no need to adopt any project managment skills: you just follow the book. Whilst the Books give the informed reader enough information to question some of the choices that have been made, as well as a starting point from which to make, or just try out, other choices, the Books are still a self-contained, and a complete, whoie, subject, of course, to a few errata after each release. Where the LFS Books might be useful, when talking about project management practices, would be in trying to document the way in which the various revisions of the Books are created, so the checks and balances that get applied to any new package that might be considered for addition - or old package considered for removal, come to that - or the way in which the various "workarounds" that have been found to be necessary are managed as and when the upstream package changes. Similarly, the discussion of the next iteration via a mailing list, or other channels, is something worthy of consideration for the field of project management, but not the Books themselves. Even the way in which the XML markup has been arrived at would make an interesting consideration for "project management" discussions. All such discussions though, are NOT a shortcoming of the Books as they exist: for me, they are very much something extra, almost something for a "book about the Books". Just my thr'pen'th though, Kevin -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
