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. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
