Leo Famulari writes: > On Thu, Nov 23, 2017 at 09:57:02AM -0500, Leo Famulari wrote: >> On Wed, Nov 22, 2017 at 10:28:49PM +0100, Marius Bakke wrote: >> > So I wonder if we should simply pick everything from this branch, >> > instead of only the few that fixes immediately visible problems. >> > Thoughts? >> >> Based on this discussion [0], I think we should take the whole branch. >> It sounds like commits on the release branches are considered important >> bug fixes and "stable". > > So after reading the rest of that thread, I'm not so sure we should take > the whole branch. > > They use the word "stable" to refer to the ABI, but the branch itself is > not tested to the same degree as the tarball releases, and may even be > in an incomplete state, depending on WIP commits. The thread ebbed out in an argument about the utility of git tags vs the output of `git describe`: https://sourceware.org/ml/libc-alpha/2017-10/msg00565.html And spawned a new thread to bump the "development" release number to 9000 in order not to conflict with long-lived release branches: https://sourceware.org/ml/libc-alpha/2017-10/msg00628.html AFAICT all commits on the branch are considered stable and nearly all are cherry-picked from master after initial testing. > On IRC Marius said that at least one thing mentioned as "incomplete" in > that thread has been completed on the branch. I think this is the email you are referring to, and actually both proposed 2.26.1 release blockers have been on the 2.26 branch a while. https://sourceware.org/ml/libc-alpha/2017-10/msg00103.html > Anyways, I don't have a strong opinion anymore about which commits to > take. But, let's make a choice and continue with core-updates :) Now that I've combed the branch history, I found that I had actually missed some fixes in the first C++/float128 roundup patch, that might not have caused problems until late in the cycle. Who knows what all those other commits do, but I trust the judgmement of the glibc maintainers more than my own regarding which patches to pick. Seeing as Fedora and IBM use the release branch, and the alternative is to carry almost every patch anyway (~1.2MiB), I prepared an update that uses a snapshot from :