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.
>
> 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.
>
I think we have one issues to address on this before we can call a
freeze. Something I experienced myself this week with that new system I
got. Grub gave a fit on a x86 nvdia sata build. It gave me the following
error when trying to set it up Error 24: Attempt to access block outside
partition. I know Joe is looking into this issue, but if worse comes to
worse, we will need to maybe switch to lilo.
>
> 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?
>
>
Actually I would like this idea, but there needs to be a slight tweak to it.
1 - PPC and PPC64 needs to be approved by Ken and Jeremy H before a
release can happen
2 - MIPS and MIPS64 needs to be approved by Joe, Jeremy U, and
myself before a release can happen
3 - Sparc and Sparc64 needs to be approved by Joe, Matt D, and
myself before a release can happen
4 - x86_64 needs to be approved by Joe, Matt D, and Ken before a
release can happen
5 - x86 needs to be approved by Joe, Matt D, Jeremy U, and Chris
before a release can happen
Now if one of the architectures is not ready for the release date, we
can do a release, and when that other architecture is ready we can
release 1.x to add it. As far an overall release manager, I would like
to see who everyone wants for this position. All devs please speak up on
who you would like in this role. I have two different individuals in my
mine, Matt D. or Chris.
But I think it needs to be a majority vote. This person would be the
release manager for 1.x of CLFS books, this person would also be
responsible for assigning any tasks that are needed for the release, if
it is not in trac already.
_______________________________________________
Clfs-dev mailing list
[email protected]
http://ninja.linux-phreak.biz/mailman/listinfo/clfs-dev
