> Date: Tue, 23 Aug 2011 07:23:23 +1000 > From: Wayne Blaszczyk <[email protected]> > > On 22/08/11 07:04, akhiezer wrote: > > > > Hi, > > > > > > I'm considering building a system based on BLFS-svn-20110728 and LFS-6.7 . > > > > > > Are Wayne/Guy/Randy/etal interested in receiving any > > patches/confirmations/feedback/&c from that process, towards a release > > of BLFS-6.7.x by end March 2012 at latest? > > > I personally suggest you should build against LFS-6.8. That is what I'm > building against atm. There have been a few issues but I think they have > been covered here. As time goes on, LFS 6.7 will become less relevent. > Regards, > Wayne.
The next release of BLFS: is it to be based on LFS-6.7 or LFS-6.8 or LFS-7.0 or what? The reason for me going on about 6.7 is from purely practical considerations; I don't necessarily prefer 6.7 over 6.8 or 7.0 or so, per se. It's instead that 6.7 seems to be the best foundation - *from where we are right now* - to getting a good release out fairly soon; most of the book seems currently to have 'builds/works with' 6.5 thru 6.7 - I don't see much/any info re 'builds/works with' 6.8 . Therefore from the point of view of getting a working _release_ out of the door, it seems sensible to go for the 6.7 base. (And then, after BLFS-6.7 is released, promptly switch the 'official' focus to a 6.8 or 7.0 basis: which doesn't prevent folks meantime working on their 'own' BLFS-6.8 etc, while the 'official' BLFS-6.7 is still in-the-works.) And, it seems to me that a good BLFS-6.7 release _can_ readily, right now, be made to be not far away: whereas if you now change the foundations to 6.8 or 7.0, then you're kinda putting everything back into the mix - you're kindof pulling the carpet part-way out from under BLFS-svn-20110728 being fairly near right now to being release-able: and you're further delaying a good working BLFS release. (Not 'you' personally, Wayne: 'you' == 'one', here.) Randy's reply ( http://linuxfromscratch.org/pipermail/blfs-dev/2011-August/021120.html ) indicated - to me at least - going for a BLFS-6.7.x release, just now, as the next release. Whereas Wayne's reply, above, seems to cast doubt on that. Wayne, what do you plan to do when LFS-7.0 is released in a few weeks' time: will you stick with LFS-6.8 (as a basis for a BLFS *release*) right through to release of BLFS-6.8; or will you switch to using LFS-7.0 as a basis, prior to any release of BLFS-6.8 (which might therefore never happen), and focus solely on BLFS-7.0 instead; or will you do the two in parallel, merging between branches as appropriate? What is the goal of your current 6.8 work? Is it a BLFS-6.8 release? Or is it more from the 'rolling compiles' approach, to keep the engine turning over 'til LFS-7.0, or what? Also, where are your current-work 6.8 patches &c being merged/committed into? Per the earlier note ( http://linuxfromscratch.org/pipermail/blfs-dev/2011-August/021118.html ), there's absolutely no problem _per se_ in folks building 'their' BLFS based on different versions of LFS, and contributing patches &c back to the project. The problem really arises when those patches &c are all rolled into a single development branch of BLFS: instead, they really should go into separate branches (BLFS-6.7.x-dev, BLFS-6.8.x-dev, BLFS-7.0.x-dev, etc), and then any mergings &c done between those branches as appropriate. If I am submitting 6.7-based patches (for the reason noted above), Wayne 6.8-based patches, and almost certainly others submitting 7.0-based patches, then where are those going to be merged to: are they all going into a single svn book? If so, then BLFS won't see a good working release prior to March 2012; by which time LFS-7.1 is released, and you can add 7.1-based patches into the mix. Meantime, other folks are holding off 'their' BLFS work til LFS-7.2; while the 6.7/6.8 folks realise increasingly clearly that - within the then-present project framework - their work isn't really going to see the light of day reasonably directly in a good working book release. What is the _strategy_ in this project, to get a release out of the door? Is the focus on getting working releases, or 'just' rolling compiles of parts of BLFS on ever-changing foundations (ie versions of LFS)? It is, of course, possible to have the best of both worlds: but you can't really get that with a single develpment branch - you would really need to have the aforenoted several development branches. I'll likely be starting the LFS/BLFS build here ( http://linuxfromscratch.org/pipermail/blfs-dev/2011-August/021119.html ) in a few days' time (the hardware is in the middle of some benchmarkings and tests and burn-ins right now). But I do need to make the calculation, is discretion the better part of valour here, when it comes to submitting patches back: is it actually better overall to contribute back by, say, putting up a public git repo of what's known-good here, instead of essentailly tossing patches onto a shifting pile that is _endlessly_ amorphous? Am not trying to be sarcastic or 'selfish' or 'ungrateful' (to others' works) or setting out on some grandiose fork, or anything like that: instead, it's just practical; and I'd expect it is a calculation that many want-be contributors realise they have to make. Fwiw: I _will_ contribute to BLFS directly, no probs, and likely for quite a long time (touch wood), if there are clear routes to good working releases established and adhered to. Randy (project lead), Wayne (current ~main-active editor): what's your plans for BLFS, in the immediate and medium and longer terms? hth, akh -- -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
