Agathoklis D. Hatzimanikas
a.hatzim at gmail.com
Mon Oct 6 13:10:29 PDT 2008
On Sun, Oct 05, at 12:49 Bruce Dubbs wrote:
> 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 think the same, there is no need for a release candidate.
> 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.
I am not sure about the announcement.
> 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.
I believe, we don't want to clean the changelog in that case, just append
Speaking for point releases, there are now (at least) three changes and
maybe there is enough justification for one:
- E2fsprogs which is in errata
- the security fix for perl
- and a broken mktemp link
it might be more, so we have a chance to test our reflexes and check how
the system works.
> > 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.
Oh thanks, although I think it would be better if you started a new thread.
> > 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 think we should provide more freedom to editors to create new
branches for whatever reason (even just to have their own book in the repository).
Look; all the serious development that took place in those 2-3 years I am
present in the project, it was after some branches, like the alphabetical
branch or/and especially the UTF8 stuff, which it wasn't even a branch, it
was a book that was sitting in the public_html of our Russian expert.
Even now, the current resurrection came after another book from the
LFS home dir, and forgive me but this is a shame. Again, I would welcome to
see editors to work in their own copies.
I guess the natural choice for that kind of development is git.
> 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.
I am pretty sure that I don't have a "need", but we are talking about
branches and releases and we need to mark the start of a new cycle with
a way, and from all the four toolchain components, (I believe) the most
appropriate package to mark this cycle, is the compiler; because is the most
fragile of all (Only the compiler can make large chunk of code unbuild-able).
You seem to prefer a cycle based on a time, which I am not really
opposite, but the funny thing is, that the six months time frame, is only
achievable today (in Linux land), by only Ubuntu, but who has paid
Again I believe that the compiler is the natural choice here, but I
won't be negative for a time based cycle.
> > 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.
I think people need to feel free to experiment, to try new things without
pressure or anything, this is development after all.
So I would welcome anything that would create that environment. A warm host
for any idea that will change the future, even if it is an idea with no
f(u|ea)ture at all.
> -- Bruce
More information about the lfs-dev