On Sat, May 27, 2006 at 11:45:46PM -0700, Jim Gifford wrote: > Jeremy Utley wrote: > > OK, we're coming close to release time for CLFS 1.0. I'm aware we're > > waiting on the new Binutils 2.17, but I'd like to propose that we go > > into a version freeze right now for all but 2 things: > > > > 1) Binutils 2.17 > > 2) Further stable releases in the 2.6.16.x kernel tree. > > I like this part.
> > This way, we can start to really flesh things out, without the worry > > of constant package upgrades, and prepare ourselves for the 1.0 > > release. I'd like to propose a target CLFS 1.0 release date of June > > 30, with an RC1 coming within a few days of the binutils 2.17 release. > > I think this is very doable. > > For those of us who don't follow the binutils list, when is 2.17 due ? [ snip grub now that it has been patched ] > > > > Second proposal will be a little more controversial, but I think it > > warrants serious consideration. We all know that by the time a new > > release of a book is made, the previous one is quite stale. So, I'd > > like to see a "release manager" nominated for the 1.0 series, who's > > sole purpose would be to take incremental updates of non-toolchain > > packages, and incorporate them into the stable tree where it's > > possible. Any updates like this should be cases where no substantial > > build changes are necessary in the book. Update releases would be > > done regularly ( I was thinking monthly), and since the changes would > > be so minor, there wouldn't need to be much testing. This doesn't > > have to be a permanent thing either - I propose we try it for the 1.0 > > release, then revisit it for CLFS 2.0 to determine if it was really > > useful and should continue. > > > > What you guys think? > > > > I'm dubious about this. The idea is attractive, but we are already spread very thinly. I'm uncomfortable with adding version upgrades - for the development book, we know things will be tested before a release, even if (for a particular architecture) something might be broken for a few weeks. Once we leave the stable branch behind, who will test architectures that its maintainer doesn't have access to ? Ken -- das eine Mal als Tragödie, das andere Mal als Farce _______________________________________________ Clfs-dev mailing list [email protected] http://ninja.linux-phreak.biz/mailman/listinfo/clfs-dev
