Hi Bruce,
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
the changes.
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
developers.
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
Regards,
Ag.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
