Dan Nicholson dbn.lists at gmail.com
Sat Dec 15 10:10:05 PST 2007

On Dec 15, 2007 5:55 AM, Randy McMurchy <randy at linuxfromscratch.org> wrote:
> Ag. D. Hatzimanikas wrote:
> > Yes thats the truth.
> > Example one. I spend much of my time yesterday to check the pdf generation in
> > mutt.
> I'm not sure what you're trying to say, Ag. We Editors try to
> work out the kinks and then document our results. What "example"
> is portrayed above? That you had to work out a minor kink in
> the PDF generation and document your findings?
> That is expected and very normal in the course of package
> updates. I wouldn't expect anything less.

I tend to agree with Ag on this one, and I think it's something that
makes being a BLFS editor difficult. To do the update of Mutt, a
package that Ag knows inside and out, he had to spend hours installing
documentation packages for a feature he doesn't care about. I would
much rather have him get the update in for the path he took and let
the options work themselves out as others who actually care about
those parts update them. This actually seems to be basically in line
with something you mention in a later reply:

On Dec 15, 2007 9:08 AM, Randy McMurchy <randy at linuxfromscratch.org> wrote:
> But you don't understand Ag, the package instructions *do* work.
> We are only providing instructions to build the package. If it
> doesn't work after a successful build, we can only hope that a
> member of the community lets us know this. If we receive notice
> that a package does not *work* as designed, then we'll take an
> appropriate action.

The current expectation of BLFS editors is that you have exhausted and
documented all possible options before committing any changes. I would
really like to change that expectation. Since we're talking about the
development book, I'd much rather see the update happen or the bug
fixed before I'm confident all roads have been explored. If Alexander
doesn't want to use HAL in his XFCE because it borks his mount
options, I don't think that should stop him from updating XFCE. Some
HAL user will come along later and things will happen to work, or they
won't and things will have to be fixed. Hopefully that user is an
editor who will know the right way to fix things.

I think this expectation stagnates development and is at odds with the
idea of bringing on new editors with less responsibilities. I also
think it works against being a community. Why should Ag be spending
hours installing the DSSSL stylesheets when he could commit his update
and a person who cares about generating a PDF could knock out that
part in 10 minutes? Instead, the diff is sitting on Ag's machine
nearly ready to commit, but none of us can see it and collaborate.

Not everyone has to be an expert in all areas, and we should take
advantage each others' strengths. To me, that's having a strong
community. IMO, I'd like to see more frequent commits to BLFS, even if
it means that it breaks sometimes. Alexander's idea of a section
explaining what's been tested has a lot of merit, too.


More information about the blfs-dev mailing list