> Date: Thu, 27 Mar 2014 17:41:37 -0500 > From: Bruce Dubbs <bruce.du...@gmail.com> > To: LFS Developers Mailinglist <lfs-dev@linuxfromscratch.org> > Subject: Re: [lfs-dev] Thoughts about LFS and systemd > > akhiezer wrote: > > > And in any event, you're still aiming at adding an "ifs'n'buts" layer to > > the lfs-main book - the type of thing that has been argued against many > > many times. > > Yes, if we end up doing this, it is a major change from our traditional > methodology. It would, in fact, be LFS 8.0. >
But still, you're running too much of a risk of main branch becoming a convoluted - epicycles 'pon epicycles - mess if it is 'exposed' too-directly to e.g. a still-rapidly-changing 'upstream' (which in this case happens to be the sysd side of things). Instead, you'd normally keep lfs-main and lfs-sysd as separate branches, and merge them into a third branch, lfs-combined. ((Aside: of course, in time, the branch names might be revised/remapped.)) Part of the reason that comparisons of lfs-main and lfs-sysd can be done just now quite readily, is precisely that they are two clearly separate branches. Could you still do such clear comparisons if you have only lfs-combined and lfs-sysd as the two branches? E.g. if you stop having a separate lfs-main and replace lfs-main with lfs-combined directly, then are you sure that you - and indeed others - will be able to auto- (or at least efficiently) and accurately generate the equivalent of a clear lfs-main book from lfs-combined, by setting a param, say USE_SYSTEMD=0 ? Are you also reasonably sure that there aren't any hard blocks going to happen: the two projects - lfs-main and lfs-sysd - may be readily-entwinable just now in their respective present states; are you sure enough that that will be the case for at least, say, the next two years? If you're not sure enough of that, then even more reason to have lfs-combined as a third, separate branch. It's also an important point that having lfs-main and lfs-sys as clearly separate branches, helps 'keep the peace' - 'good fences / good neighbours' - and helps keep respective groups 'happy': each can get on productively with doing the respective works that they enjoy; and as a fairly direct by-product of that, one can see clearly how readily can the two branches be merged into the 'lfs-combined' branch/project. So, having lfs-{main,sysd} as separate branches, is not a pointless unnecessary burden: on the contrary, it's having them clearly separate, that contributes in large part to lfs-combined being so readily do-able. > > I do think that the idea is of interest: but it's really a candidate for > > a separate branch/project. > > So far I've just added some packages that sysd needs but doesn't change > the essence of the book a lot. But those packages would auto- drop-out if a user is building/following the non-sysd track of the book, right? You _would_ tell them that they don't need to build/do those packages/steps: or would you let a few 'innocuous' ones slip through unmentioned and have users build them anyhow - e.g. for devs' convenience if you hit (as is reasonably predictable) a bind. IOW, if it's convenient for devs, would you quietly have non-sysd users building stuff that's really genuinely only required for the sysd side? > Adding sysd is where things really start > to change. After I do some work in my sandbox, I may indeed create a > separate branch, which, btw, is not really much more than the git > method: cd ../../branches; svn cp ../trunk/BOOK experimental In case that last point is re the earlier remark about git branches being 'inexpensive': it wasn't said that the inexpense was just concerning the creation of branches; but rather, overall - and in particular central things like rebasing. The activity that you're embarking on, would almost everywhere else be done on a separate branch. I've encountered - whether directly or indirectly - only very rarely, projects where it's decided to essentially refactor the project directly on the main branch. You say that if it doesn't work out then things can just be reverted. That's far easier to do on a separate branch - or indeed just blow the branch away - than it would be to essentially, in practice, have to cherry-pick which commits you want to revert from a main branch ... 'cos you'd earlier gone'n decided at some point, for some reason, to do 'experimental'-branch-type work, on main trunk ... . rgds, akh -- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page