On Tue, Oct 18, 2011 at 12:21:19AM -0700, Qrux wrote: > > On Oct 17, 2011, at 10:56 PM, DJ Lucas wrote: > > > "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. > No, that isn't what currently happens - old things are still in the book. BLFS is good at providing choices and alternatives, at least for the older packages, but they remain in the book for ever, or at least until someone notices that they are irretrievably broken and cares enough to rip them out. More generally, old ignored versions languish in the book - not necessarily totally broken, but certainly not supportable.
> > 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. > Again, no that isn't what happens at the moment. But who knows which parts of the book actually get used by end users ? Sounds perfectly sensible, but will be very disruptive. For a start, it probably means creating a branch (not svn's strong point) and then copying things in as people express interest. For each chunk that gets copied, perhaps quite a lot of work to create internal links for things NOT being pulled in (obscure dependencies), and then a check that you haven't now pulled in what someone had earlier made an external reference and, if so, fixing that up for the again-in-book page. If there is interest in actually getting a release out (and some agreement about which version of LFS it is targetted at), perhaps the simpler approach would be for someone to become release manager and indicate which areas lacked maintainers (initially, most of the book), then whittle that list down and eventually mark the packages as deprecated, with a note that in this case it means nobody is interested in maintaining it. I might be willing to spend some time on the packages I care about (particularly the abiword and gnumeric parts of gnome-office, also the gimp, ghostscript, cups [ I can feel already that I'll regret saying that for gs and cups, so maybe I'll change my mind ], gutenprint while I continue to use an inkjet, and ImageMagick (the package which probably has the most releases of any, and where finding out what changed and why is always difficult - sometimes, it works fine for my uses, more often it doesn't). Of course, even the gnome-office stuff (including office-specific dependencies, obviously) tends to have issues as the version of gnome itself changes. If I was really keen to come back to this rather than playing with my trainset, I might even express interest in firefox (which is now a female dog in terms of using system libs for html5 dependencies) and some of the AV stuff. But I warn everyone, I've spent too many hours in the past on trying to get towards a BLFS release. I would need to have a lot more confidence that a worthwhile release was actually going to happen. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
