On Oct 17, 2011, at 10:56 PM, DJ Lucas wrote:
> On 10/17/2011 11:42 PM, Ken Moffat wrote:
>>
>> But, your core already appears to contain things that I have no
>> interest in, nor need for. The strength of BLFS has always been
>> that you can pick the things you want. The idea of a 'core' implies
>> it should always be built.
>
> And this is the crux of the problem. The goal, if there ever was _one_,
> has been overshadowed by the complexity of committing a single change.
> This is a deterrent that should not exist in a development book. I
> personally have no problem with the BLFS-Core, BLFS-LAMP, BLFS-LAPP,
> BLFS-KDE, BLFS-LXDE, BLFS-Gnome BLFS-Whatever books, except that it'd be
> a lot of duplication of effort. For instance, the BLFS-Gnome book would
> contain pretty much all of the book except the server and the majority
> of the KDE packages (and add about 70 others in order to be feature
> complete).
"I personally have no problem with [BLFS-*], except that it'd be a lot of
duplication of effort."
I hate to seem callous for a Johnny-come-lately, but...So what? If there's
huge overlap between BLFS-KDE and BLFS-Gnome...Well, that's on the KDE and
Gnome guy(s). If one falls into disuse, then it's just being "selected out",
however naturally or unnaturally. It seems ironic that there appears to be
confusion between having choices and being chained to those choices.
If, for example, you're a KDE user--and so you maintain the KDE parts of the
book--and the BLFS-Gnome parts of the book just fall into disarray from
disuse...So what? Someone who cares will pick it up. If not, deprecate it.
Why view this as a problem? If it's not being actively maintained, that's
already what's happening de-facto right? You're not using it. And, no one
else is--or, cares enough that it's not being maintained.
> I too think the organization should be better thought out, but my
> preferred method of attacking that problem would be equally unacceptable
> for the very same reasons. I'll go ahead and suggest it anyway though,
> let us start with only the stylesheets and the introductory chapter,
> then add or migrate whatever it is that you feel compelled to add. This
> would at very least weed out the cruft that nobody cares to maintain,
> but I no longer have the time or inclination to maintain and/or
> contribute in order to get the book to a 'stable' state, which puts us
> right back full circle.
Why is this "equally unacceptable"? Maintain the stuff you use. Hope that
there are others to maintain the parts they use. If there are things that just
don't get used--and therefore don't get updated...Then, let them fall out.
Again, that's basically what happens anyway, right? So, just legitimize it.
Have a process, though, that "stamps" what *is* being maintained with a
"release", and have a mechanism to deprecate what isn't being maintained. It's
not like getting "stamped" "deprecated" is a death sentence...someone who comes
along later can decide to pick it up.
It seems, you're basically coming to the same conclusion. Reduce BLFS until
you can find a subset that's feasible to maintain. If that's just the
stylesheets and the intro chapter, then fine--though I happen to think the line
would go past Section II.3. There already seems t be some consensus on what
"Core" might be.
Again, it seems we're reaching the same conclusion. Left as it is, it's just
falling into a never-ending-moving-target without releases that correspond to
LFS. And, maybe I'm just getting the wrong idea here, and making an
inappropriate association, but isn't having a BLFS that can't track
LFS...kinda...silly?
Q
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
