On 6/25/19 8:45 PM, DJ Lucas via blfs-dev wrote:
On 6/25/2019 6:21 PM, Joe Locash via blfs-dev wrote:
Seriously? Ok, so missed a couple of packages.
Maybe I shouldn't contribute to the goal of the project. My bad.
Joe, your frustration is noted. Perhaps you wouldn't be if, as editors,
we communicated better. Please allow me a moment to alleviate the
confusion of why it's a huge difference in effort and provide some
unrealized context.
As a user, you can probably get this installed and working in just a
couple of hours (as can I or any of the other editors here, and most
long time users). For editors, however, it's a bit different, and I'm
sure this is probably somewhat obvious to you, but the required amount
of time invested is probably not what you'd picture without having
inquired.
For starters, you need to figure roughly four hours of time to add a new
package to the book correctly. This varies depending on complexity of
said package, and interactions with other packages, but four hours is
the average. This includes the following tasks:
1. Find multiple official download locations if available
2. Verify developer signatures if available
3. Verify documented sums and document locally
4. Examine configure, meson.build, or cmake.lists manually to verify
that there are no missing dependencies that are excluded from output
when other dependencies are present
5. Document all dependencies
6. Determining which dependencies are required
7. Determine which dependencies are optional
8. Determine the recommended dependencies based on the subjective best
guess of what is common usage
9. Document all of the above and remove nested dependencies
(dependencies that are covered by another dependency in BLFS or that are
in LFS)
10. Determine appropriate configure/meson/cmake flags as well as any
CFLAGS required, or other tweaks that need to be made
11. Verify that most common builds work as expected, these being:
a. required
b. recommended
c. everything and the kitchen sink
d. multiple random assortments of common optional libs to ensure that
there are no odd combinations that break
12. Author a standard set of instructions
13. Do multiple 'standard' builds to verify and document timing and
build size, both at -j1 and -j4
14. Document every file that is installed, and where (DESTDIR and tree
help)
15. Find descriptions for each executable and library installed (which
more often than not, means having to read the source code for libraries
that are installed alongside executables for which the package is named)
16. Work through test suites, identifying and documenting any failures
17. Author introductory text and surrounding text for instructions,
explaining the steps if necessary
18. Put all of the above into an arcane XML format that is suitable for
both human consumption after rendering, and machine consumption for
automated builds (note: all of the steps above, and this very last step
is the largest time sink and largest bar to entry for new editors and
contributors).
Doug was onboard and interested with the initial estimate of 3 packages.
Assuming four to six hours of free time per day for the average working
adult in the states, you asked for two or three days of his free time,
which, again, he was on board with. When that ballooned into six, seven,
or eight days (or giving up an entire weekend), it became more of an
endeavor, so yes, missing a few packages is actually a big deal when you
put it on those scales. Your input is appreciated, and us asking for you
(or any other user) to provide a proof of concept acts as kind of a
gateway to inclusion. This is the work you are asking to have done. You
do the first tenth of it to prove that it's viable. Obviously, if you
were to go for the real source, it'd be so very much more appreciated,
but having done this myself for the better part of the past 20 years
that I've been working with LFS, I find it really difficult to point a
user to the book source on first suggestion for a POC. I'd rather you
not invest that much time into something that may or may not become a
reality, hence the request for a rough outline and sequence of packages.
And finally, being Gnome packages, they often are on the easier side,
but I think you can still appreciate that it's far more than the two or
three hours to get it right off the cusp.
I hope that gives you a more realistic understanding of what is involved
with moves, adds, and changes in the books and might serve to ease the
frustration exhibited above.
And to add to the list, lets discuss maintenance. We will need to
update currency scripts to check when new versions of a package is
released. When it it released, it has to be built and tested. Finally,
even if it is not a new package, every time we release a new version of
BLFS (twice a year), the package has to be built and tested to see how
it integrates with the hundreds of other packages in BLFS.
Last year we removed lxqt, just because of the maintenance burden.
Also note that LFS/BLFS is a 100% volunteer effort. No one is supported
for doing the work of LFS/BLFS. In fact we pay for our own equipment
and for the hosting service. We do this purely for the satisfaction of
supporting the Linux community.
With more editors, we could do more, but the process is not easy and
volunteers few.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
