LFS Milestones

[DJ Lucas]

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

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.