Glibc stable release process (Glibc 2.26.1)

[Joseph Myers]

On Wed, 4 Oct 2017, Arjan van de Ven wrote:

> On 10/4/2017 1:36 AM, Andreas Schwab wrote:
> > On Okt 04 2017, Siddhesh Poyarekar <siddhesh@sourceware.org> wrote:
> > 
> > > 0. Must not break ABI on that branch
> > 
> > We must not break the ABI on any branch.  What you probably mean is that
> > we must not extend the ABI on the release branch.
> 
> and no new symvers
> 
> I'd expect this to be both backward (like usual) but also forward compatible
> as a goal.
> 
> now if a CVE requires a new symver, I'm sure that will trump that rule

Even new GLIBC_PRIVATE symbols are risky for package updates on live 
systems (as you get the situation where a process had loaded libc.so not 
providing the symbol, then glibc is upgraded, then that process loads 
a newer libm.so which expects a GLIBC_PRIVATE symbol from libc.so that 
only newer libc.so provides - a real issue that appeared with backports of 
nan unbounded stack usage fixes).

-- 
Joseph S. Myers
joseph@codesourcery.com