dj at linuxfromscratch.org
Sun Oct 5 01:00:58 PDT 2008
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.
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...
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 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. 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. 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).
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.
-- DJ Lucas
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
More information about the lfs-dev