On Mon, Nov 24, 2008 at 09:50:09PM +0500, Alexander E. Patrakov wrote: > Ken Moffat wrote: > > It also doesn't solve all of my issues - I'm happy with xorg-7.4, > > but I'm building a lot less than some people, and using a different > > form of automation. I'd prefer to leave xorg to people who follow > > the book's method. > > Yes, sure! > > > I could throw in the toolkits (gtk+ and so forth), > > but they won't be a lot of use without xorg. > > Yes, you'll have to wait until someone throws in xorg. > > > And until the branch > > has enough to be useful, we can't expect users to test it. > > Correct, but irrelevant. This is strictly for testing by the Editors. > > > Also, branching seems unnecessarily complex and I don't see what it > > gains (apart from potentially identifying "nobody cares and has > > time to fix this" packages). > > Detecting broken stuff that nobody cares about was my primary intention. > The second expected achievement is detecting packages where every editor > deviates from what's written in the book. Besides, it gives you chance > not to care about compatibility with the existing stuff. > > > I think that creating an almost empty > > branch (chapters with very little in them - but with enough to get > > it to render) will be a lot of work, and adding package details back > > in will take more work than just editing what is in trunk. > > Well, there may be other solutions how to get from the current state to 6.4. > For a release, digging out things that no current editor cares about might be a good idea. I'm more interested in getting fairly quickly to a book which is less broken for desktop users of LFS-6.4 than what we now have, and without making things harder for editors.
ĸ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
