On Thu, Jul 31, 2014 at 09:03:45AM -0400, Rahul Sundaram wrote: > Hi > > > On Wed, Jul 30, 2014 at 11:12 PM, Siddhesh Poyarekar wrote: > > > > > 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. 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. > > > > Yes. My concern is that glibc is using Rawhide as their continuous > integration sandbox to shake out bugs as opposed to doing it elsewhere and > just taking care of integration of releases when they are ready. I'm actually not concerned about Rawhide being used like this. That's kind of the purpose of Rawhide. However the previous problem(s -- multiple) was glibc using non-Rawhide for integration testing, especially just while we were trying to stablise Fedora for a release: https://lists.fedoraproject.org/pipermail/devel/2011-October/158440.html https://lists.fedoraproject.org/pipermail/devel/2011-October/158662.html But 2.20 is a stable branch, right? So this shouldn't be a concern now. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
