| From: |
| Florian Weimer <fweimer-AT-redhat.com> |
| To: |
| "Andreas K. Huettel" <dilfridge-AT-gentoo.org>, libc-alpha-AT-sourceware.org, siddhesh-AT-sourceware.org |
| Subject: |
| Re: Glibc stable release process (Glibc 2.26.1) |
| Date: |
| Mon, 2 Oct 2017 21:22:12 +0200 |
| Message-ID: |
| <a30cc34e-f71f-8e8a-1b99-1c3c1b798e84@redhat.com> |
| Cc: |
| Zack Weinberg <zackw-AT-panix.com>, "Yann E. MORIN" <yann.morin.1998-AT-free.fr>, Tulio Magno Quites Machado Filho <tuliom-AT-linux.vnet.ibm.com>, Romain Naour <romain.naour-AT-gmail.com>, Joseph Myers <joseph-AT-codesourcery.com>, "Gabriel F. T. Gomes" <gabriel-AT-inconstante.eti.br>, Paul Eggert <eggert-AT-cs.ucla.edu>, Arjan van de Ven <arjan-AT-linux.intel.com> |
On 10/01/2017 09:59 PM, Andreas K. Huettel wrote:
> To be honest, if I were a long-time glibc distro maintainer I'd probably agree
> with you and prefer hand-picking. Starting from a tag / tarball is something I
> prefer because I'm not that versed with things yet.
We continuously rebase Fedora on top of the upstream stable release
branch for that Fedora release (but we do not switch branches within a
release).
I doubt there is a clear preference, and each approach has its
advantages and disadvantages.
I still don't understand why you need tarballs for releases, though. or
put differently, the difference between glibc 2.26.5 and glibc 2.26-40
seems rather minor to me, and producing the tarballs is quite a bit of
work for us.
Regarding security backports, you really need to read and understand our
announcement of significant issues anyway. People keep rediscovering
semantically dependent patches in glibc 2.19 for the CVE-2015-7547 fix
because the posted patch applies without conflicts without them, and
this despite we clearly named those patches in the release announcement.
This is why I'm wary of pretending further that things are simple.
They are not.
Thanks,
Florian
