LFS Milestones

Agathoklis D. Hatzimanikas a.hatzim at gmail.com
Sun Oct 5 03:05:34 PDT 2008

On Sun, Oct 05, at 03:00 DJ Lucas wrote:
> Bruce Dubbs wrote:
> > I have added a new milestone, 6.4, for the current effort.  It can be removed if 
> >   the consensus is that what we are currently working should be 7.0.
> >
> > My understanding is that we are updating the packages currently in the book, but 
> > no major changes are being made yet.  If we do 6.4 and then proceed to 7.0 with 
> > 64-bit changes, then we are taking smaller, more manageable steps.
> >
> > Comments?
> >
> >   
> Yeah, actually. 6.4 sounds good to me. I do have a question, or rather a 
> suggestion about policy, however. This is long so bear with me...

Hi DJ and thanks for doing this, really.

> Why do we not use Subversion branching more effectively? Just lack of 
> developer interest? It seems reasonable, to me at least, that we should 
> branch for a release, and we do. However, we have yet to take advantage 
> of it. Errata shouldn't sit around for 2 or 3 months, it should be 
> addressed by a new micro release in the release branch if the changes 
> are not too invasive. Take for instance the Perl-5.8.8 security patch. 
> Micro package revisions can also take place here.

Undeniable, point releases will eliminate these kind of problems and
quite probably will make LFS more attractive in a production environment,
since all the security fixes or updates that aiming to fix serious problems,
can be backported.
We just need a man to maintain the branch. He doesn't have to be a toolchain
expert, he just needs to understand how the revision control system works,
note that I didn't said subversion.

> solve Ag's concern for skipping a release based on gcc-4.2 (see next 
> paragraph for that).

It does solve this problem as well.

> The same thing goes for the development book. This requires somebody to 
> define a set of goals and a time frame for the next minor release (or 
> major version) of the book.

Aha, this remind me the lack of roadmap, because I was under the impression
that FHS compliance was a target for the next release. I found myself in
that position just 10 days ago, when I wanted to use (FHS compliance) as
an argument in the track, I just couldn't do it because there wasn't an
official roadmap. This leaves to anyone to interpret different the goals
of the next release and that isn't a sign of health (usually).
I guess Bruce's parent thread is some kind of a roadmap and I would welcome
if there was a sort roadmap at the root directory of any new branch, from
now and on.

Saying that, it would help if there was a set of pre-defined rules to
guide the editors through editorship duties.

> At some point, we should branch when a clear 
> set of goals are defined for the next release. The fun part is that this 
> should happen fairly *early* in the development cycle. This, in effect, 
> is an answer to Ag's previous concern. In that branch, we would require 
> that changes are checked pretty thoroughly, much like we watch over 
> trunk today. Basically, we have a set of goals now, so IMO as soon as 
> the big list of package updates are done, we should branch for 6.4, not 
> *after* trunk is proven to be stable-ish.


> This leaves trunk open for immediate updates. This would keep developers 
> active and interested IMO. Some breakage is acceptable in trunk after a 
> branch is created for development.

Exactly, and not only that. In my opinion trunk should be considered broken
by default.

> Not until a major or minor release is 
> completed, should we start to focus on stabilizing trunk. Package 
> updates can go in as soon as a developer is able to do an increment and 
> a package build, without worrying too much about breaking other parts of 
> the book (this would be akin to the personal book I did). While there 
> were several minor errors (test suite results weren't correct, a switch 
> for file-4.25 was broken, LSB-Bootscripts were added, chapter 5 gcc was 
> broken without GMP on the host, some text didn't quite gel up correctly, 
> etc.), they were not detrimental and still produced a working product 
> that was logically in line with the next release of the book.
> This is also where other experimental branches, focused on a specific 
> goal, would be born. Take Jeremy's branch for the multi-platform builds 
> (32 and 64pure) in the same book for example. Bi-arch, PM, and LSB could 
> also happen in a branch when/if (when) the time comes, and later be 
> merged into trunk. Major versions of the more important packages could 
> happen in a branch as well (gcc-5.0, glibc-3.0, linux-2.7, etc.) They 
> can later be merged and removed (or just removed should branch 
> development make an unfortunate U turn).

I agree with all you said, because those were my requests too in the
The thing is that it may be easier to work with git for that kind of
development scenario. I think we should ask the developers and if there
is an agreement we should move to git.

> It is my hope that branching early on, and being a little more lax with 
> trunk and its freedom to create more branches would keep people 
> interested in contributing. Much like the LFS-Hackers list provided some 
> time ago, but with more definition. BTW, I miss the lfs-hackers list! 
> ;-) Toying on the bleeding edge and finding or making the solutions is 
> fun for me and I enjoyed taking part in the hackers discussions. I think 
> the editor role has to be fun or nobody will want to do the work.

Funny, I told the same to Richard yesterday. Development is an inner
need so what we have to do is to make easy for people to contribute and
work in a interesting environment.

But the truth is that we don't give that supplies.
I've read today that Matthew fixed the permissions in Track, but I already
reported that at least two times in the past year.
Sometimes LFS organization it doesn't looks flexible enough and too
bureaucratic. There are people that could help from other positions,
positions which they don't require technical skills.
I mean, from simple tasks like editing the front page or to fix those
broken permissions in trunk. We need a small management team of 3-4

Plus and at the end, we need a man responsible to take decisions and give
directions. A dictator for every 8 months months maybe?

> I feel  > that this is where we were a few weeks ago. As soon as something new 
> (and/or interesting) came along, people started piping up. At least, 
> that's how I have seen it over the past few weeks.

Thanks again for this post.

> -- DJ Lucas


More information about the lfs-dev mailing list