GCC patch

Gerard Beekmans gerard at linuxfromscratch.org
Thu Mar 7 15:00:26 PST 2002


On Thu, Mar 07, 2002 at 11:22:02PM +0100, Marc Heerdink wrote:
> If I understand correctly, you jumped off the idea of implementing the
> keep_chap_etc hint right after releasing 3.2? That would make it
> impossible to release a book in the 3.x style, because that hint will be

That's right yes. The keeping chapter 5 and 6 seperate, as well as the
gcc-3 switch-over are two things that won't go in a possible 3.3 for sure.
There are 72 outstanding items, some of them are not big ones, just petty
problems like layout, spelling, grammar, whatever else people have added.

The natural course of action would be to take care of all the smaller,
minor things first. That way if a 3.3 release is imminent, it won't include
a new gcc or the keep-chap5+6-sep change (we really have to find a better
abreviation for that).

> the major change in 4.0.... or did you find out how branches work in
> CVS? ;-) Anyways, I don't think getting 4.0 ready will take more than
> two months :-)

I have a vague idea of branching. I've read up on it and I know how to do
it, but the problem is that there has to be more dicipline amongst the book
editors (currently me, marc and mark). One of the things I'm going to work
on after the 3.2 release is the LFS editors manual. It'll be a straight
forward check-list type of thing that you'd use to do certain things.
It's often easy to forget certain steps in a process, this manual should
help with that. Working with different CVS branches will be covered in it
too, when the time's ripe.

So, until then we'll stick with the one MAIN branch.

You don't think getting 4.0 ready will take more than two months. I
wholeheartedly hope so too. Let's get down to some bug splatting then.

-- 
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