On Wed, Jul 30, 2014 at 03:36:34PM -0400, Matthew Miller wrote: > > > The changes in the rebase should be minor since we've > > > been tracking master the whole time. > > I remember a similar process causing problems in Rawhide earlier and Jared > > Smith talking with the glibc team to ensure that only regular releases hit > > rawhide. The problem with that approach is that lots of bugs go unnoticed until very late in rawhide, resulting in those bugs being caught and fixed only post-release. Besides, this process is different in principle from the earlier one because the earlier process simply cut the latest master into a Fedora release just days before Fedora went gold. In the current process the glibc release Fedora gets is decided well in advance, that is when the Fedora release branch is cut from rawhide. Combine that with the fact that glibc upstream freezes weeks before it releases and you'll see that the glibc release that makes it into a Fedora release is eventually well tested in rawhide *and* is not ancient. > It would be nice if we're careful in staging ABI changes in the glibc master > into Rawhide so it doesn't break. (Possibly something we can do with > Taskotron?) ABI changes are a minor problem with respect to glibc because as a principle, we don't break ABI. That is, any ABI breakages that happen are usually bugs. We try to ensure that with a basic ABI checker in the glibc testsuite and in future we'll be looking to enhance our ABI checking capabilities. Taskotron (based on a quick read from the wiki) seems to be a good framework for this. The bigger problem is bugs that brick your system because unlike kernel, there is currently no way to simply reboot into an older known-to-work glibc. We had one such situation last week and IIRC the last such situation before that was close to two years ago, so while it is serious, it is not frequent. That said, we're also thinking of ways to recover from such botched updates. Siddhesh
Attachment:
pgpSNm7RohRE6.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
