LFS Milestones

Bruce Dubbs bruce.dubbs at gmail.com
Sun Oct 5 10:49:07 PDT 2008

DJ Lucas wrote:
> Bruce Dubbs wrote:
>> I have added a new milestone, 6.4, for the current effort.

> Yeah, actually. 6.4 sounds good to me.

OK, I have fleshed out the description of 6.4 and 7.0.


I've set a tentative target date of 6.4 as November 1 with the limited goal of
updating all packages to latest stable releases.

For 7.0, the tentative target date is March 31, 2009 with the goals:

   * Add x86_64 64-bit instructions
      o Still to be decided if a pure 64-bit or mixed 64/32-bit system should be
   * Add introduction to Linux Standards Base
   * Update packages to latest stable releases

We can discuss and change anything here as appropriate, but I set this up as a
basis of discussion.

> I do have a question, or rather a suggestion about policy, however. This is
> long so bear with me...
> 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.

That seems reasonable.    It
would not be hard to branch a 6.3.1 from 6.3 and commit changes to that as
appropriate.   I'm not sure what the release procedures should be.  Do we do a 
-rc1, etc for a minor errata change?  I am thinking that would be overkill.  I 
suppose that a message that the branch is ready to the -dev list would be enough 
to decide if it's ready and then go through the normal process of building the 
book in the various formats, updating the web site, and making the announcement 
would be appropriate.

As an aside, how do we handle the change log?  Do we leave in all the changes 
form 6.2 to 6.3 and add the changes for the point release to the top, or do we 
just put in the changes made in the point release.

> That doesn't quite solve Ag's concern for skipping a release based on gcc-4.2
> (see next paragraph for that).
> 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. 

I just did that, but of course we can change it if we can develop a consensus 
about what changes are needed.

> 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 sounds a bit like what we did once before where we had an experimental 
branch as well as the -dev branch.  This used to be for bleeding edge stuff.  I 
really don't think it is necessary at the level of changes that are currently 
being made.

I'm not sure I understand Ag's need to have a release for every gcc version. 
That makes an LFS release tied to the gcc release cycle.  I don't think we want 
to tie ourselves to that.  Also, as noted before, the full tool chain of gcc, 
binutils, and glibc are the critical packages that all the others depend upon. 
On top of that, as DJ noted, there are no formal release cycles for glibc any more.

I would be more in favor of just having a target minor release cycle of every 
six months, say Feb 1 and Aug 1, where the packages are updated.  As editor time 
and interest allows, then fold in more significant changes within that cycle.

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

We can do that now.  I think we should branch when the current packages and any 
other changes are in the book for the first time.  Basically this is when we 
freeze package versions for the release.

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

There is nothing stopping an editor from branching for experimental purposes 
like Jeremy did with his pure 64-bit version.   It doesn't have to be done at 
the head of the -dev version.

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

Why do you miss the hackers list?  Anything there can also be posted on -dev. 
Go for it.

I agree that participation of the editors is governed by their enjoyment of the 
process.  What generates that enjoyment varies by personality.  Generally, I 
think appreciation of the work done to produce something useful is what 
motivates most.

   -- Bruce

More information about the lfs-dev mailing list