Matt wrote in ticket #2576: E2fsprogs-1.41.10: New version. Release notes at http://downloads.sourceforge.net/project/e2fsprogs/e2fsprogs/1.41.10 /RELEASE-NOTES?use_mirror=freefr.
There are a substantial number of bug-fixes in this release, so not sure whether to target this for 6.6 or not. I'll leave that up to Bruce :-) ----------- It's not really up to me, but I think we need to discuss the strategy of making updates during an active release phase. 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. 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. That may be overly aggressive though. My reasoning is that a user can always regress to an earlier package if problems arise. Perhaps we should use the 'dot' rule for everything. That is if a package goes from x.y.z to x.y.z+1, then include it, otherwise not. If we are within a day or two of release, then it would need to be a really major security bug functionality to make any package changes at all. I'm interested in other opinions. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
