unstable branch for LFS

Gerard Beekmans gerard at linuxfromscratch.org
Tue Oct 15 13:10:33 PDT 2002


On October 15, 2002 06:15 am, Matthias Benkmann wrote:

I'm about 300 lfs-dev emails behind, so i'll try to catch up asap. This time 
it was due to Thanksgiving. Me and my wife decided to go out to the lovely 
mountains for a bit. I come back, hords of email.

Okay....unstable book. Yes sounds good, yes I want it, yes long time ago that 
probalby nobody but me remembers I once wanted to do it but due to time 
constraints we decided not to do it yet. That's not an issue anymore really.

I haven't read all the replies to this thread, but one I did read was that it 
might be hard for us the editors to maintain two seperate books. Since if we 
make a change to the stable book we should make that same change to the 
unstable book to keep them in sync right? That way an unstable book can be 
released a stable book later down the road easily since all the stable book 
elements are already present. This ideally is done without us making the same 
update twice in two directories.

So I propose this: we can use one and the same XML tree to house both the 
unstable and stable books. Anybody remember me talking about dynamically 
render a customized lfs-book by switching some XML tags that add/remove 
certain pages/chunks from the book?

Similarly we can easily add "unstable" XML sections that are only visible when 
you enable an entity. If disabled (by default) a normal stable book is 
renderred.

To me that sounds like the easiest solution. But then there's CVS - it'll be a 
tad harder to keep track of the changes and revert back to older chagnes as 
you have to figure out which commits were updates to stable or unstable 
branches. Having a seperate unstable branch has quite a bit of good points 
when it comes to revision history and all the likes and will increase our 
workload a bit. Just one branch that does it all, but smart usage of XML 
techniques, will make it easier for us (editors) but a bit harder for 
administrative purposes. Now the latter most people don't care about, except 
for the editors themselves. I'll think this through more thoroughly and give 
a definite answer soon. In the mean while feel free to come up with your own 
ideas how this can work nicely.



-- 
Gerard Beekmans
www.linuxfromscratch.org

-*- If Linux doesn't have the solution, you have the wrong problem -*-
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list