Randy McMurchy wrote:
This, IMHO, is a highly optimistic view. For each upgrade, and some packages have new releases on a pretty frequent basis, you have to perform a full build of the package, into a non-standard directory, measure the build sizes, compare the binaries installed with those on the current list, then research the function of each new binary, assuming information is available on what that binary does. Then, you have to properly edit the XML, validate it, ensure the new XML code renders into HTML properly, and finally commit it. This process is much more than the 5 minutes you suggest it should take.
What do you mean a bother? For almost all the packages in the
book that build in just a minute or two, it would take less
than 5 minutes to update the build entities, installed programs
and libraries in the book.
Well, lets look at it differently. Lets take, for example, a certain package that undergoes 10 upgrades thru a LFS release cycle. Assume 10 minutes for testing a build (without installation), updating the package version entity, testing rendering, and committing - and this is a highly optimistic time estimate. We'll also assume an extra 30 minutes for installing the package to a non-standard directory, validating all installed binaries/libraries, and researching any new binaries that may be present in the build.
I don't see any need to omit it, because "it's a bother". Seems as though it's just part of the job. Then somebody doesn't have to go behind and do it all at one time in a time-crunch release it tomorrow mode.
Taking this into account, if you update those parts of the XML only once, before release, then editorial staff has spent just a little over 2 hours on that single package thru the release cycle (10 upgrades x 10 minutes + 30 minutes checking prior to release = 130 minutes). Meanwhile, doing this for every one of the upgrades would be nearly 7 hours (10 upgrades x 40 minutes = 400 minutes). So, in this sample case, by waiting for release to edit these items, the editorial staff has been saved 270 minutes, or 3.5 man hours - and this is just for one package. And, as I said, and speaking from my own experience editing the book, these time estimates are highly optimistic - only the simplest of upgrades can be done in a 10 minute period, even without updating the build sizes/installed binaries parts of the XML.
Holding the upgrade of these parts of the XML is simply a more efficient use of the editorial staff's time, especially when you consider the fact that anyone using the development version of LFS would logically be expected to know how to find out this information for themselves, as they are experienced LFS builders already.
Of course, if it's that important to you, the LFS editorial staff always welcomes patches to the book's XML :)
-J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
