Bruce Dubbs wrote: > There are 58 packages in LFS. If we put out an -rc version for a month, > on average we'll have 4-5 packages updated in that time. Do we > incorporate them or not? If we do, we reduce the time for testing and > feedback, at least for those packages. If we do not, then we're > automatically out of date. > > The longer we have an -rc outstanding, the more likely we are to have a > new package version of some kind released. > > How do we decide? > > I don't have a problem with a dot release in the kernel. That is > 2.6.32.7 -> 2.5.32.8. I don't think we should update to 2.5.33.x if > that is released.
Seeing as 2.*5*.33.x would be a downgrade then no, I don't think that's wise :-) I'd agree though, upgrading to a 2.6.33 release would be too unsettling at this point. > I don't think we should update glibc or gcc unless there is an > indication of a major flaw or security bug. bunutils should probably be > in the same category. > > I'd be very reluctant to update autotools. > > 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 agressive. 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. 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. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
