Matthew Burgess wrote: >> Almost anything else, I'd say that we should check the build, do an -rc >> for a week and release. > > I think that is a bit too aggressive. I think LFS does well to keep as > up to date as it does to be honest, and the only reason it does that is > because it is so (relatively) small. The fact is, unless every package > we used was to commit to the same release schedules we will always find > ourselves in a position where a new release of at least one of those > packages is made during our RC phase.
> Therefore, I think the decision/strategy is quite simple; we simply do > not upgrade *any* packages once we hit RC stage. During the RC phase > the only work we do is fixes for the build/integration of package > versions already in place, or the explanatory material around them. I > think our security advice is already quite clear (i.e. you are on your > own), and we can easily push out post-release errata if there are any > major security flaws during/after a final release. I do recall updating some packages in the -rc phase in the past. I can agree with your approach in general, but we should review each new package package release and evaluate whether it is really necessary to add that too the candidate book. What about Linux-2.6.32.8? We already say in the book "The latest available 2.6.32.x kernel version should be used, unless the errata page says otherwise." > The RC stage itself should be on the order of 1 month in order to give > users time to give the RC a spin, report issues, for us to fix them, > rinse & repeat. It also gives folks time to get through enough of the > BLFS packages for us to be fairly confident our toolchain holds up and > isn't going to cause folks pain once they leave the comfort of LFS. Yes, I agree with that. Perhaps though we should now be updating the tickets against 6.6 in -dev and later tag -dev to -rc2 or stable. After stable is released, only then update the packages for milestone 6.7 in -dev. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
