glibc 2.23 -- Hard freeze follow ups

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

Hi all,

Following the initial 2.23 hard freeze starting discussion, this thread
is to discuss current blockers and desirables features and considerations
about them.

I think Roland has summarized a good strategy on how to consider a block
and a desirable features, so I will reproduce it here (with some adjustments).
I also plan to update the release wiki with these points:

1. Known release blockers: these are bugs that it's important enough to
   fix that we don't want to make a release without them fixed.  For
   anything that is not a build breakage or a user-visible bug (e.g. new
   functions, new features, internal revamps that don't directly fix
   blocker bugs), then it should *not* be considerer as a blocker.

   1.1. One acceptable exceptions are cases of pathological 
        performance in some use case that matters, or nontrivial 
        performance regressions from a past release.
   1.2. Another acceptable exception is new functions that's required
        to work with other GNU packages like GCC or Binutils that will
        be released before the next libc release cycle.

2. Important features/fixes: these are changes that are desirable 
   enough for some reason that it's plausibly worthwhile to destabilize
   the tree a bit for their sake.  The main characteristic these have is
   that the release manager and maintainer consensus are relatively
   easily convinced that we should allow changes in after a freeze was
   declared.  
   They are *not* blockers and usually after hard freeze announcement
   it should be allowed up to maximum of 2 weeks before the branch
   creation to patch being sorted out and pushed upstream.

3. Nice to have: These are changes that are desirable enough that they
   should have higher priority than other things not in one of these
   three categories.  They do not rise to the level of importance
   necessary to risk destabilization during freezy times. 

Based on that I have changes:

* "[BZ #19329] Fix race between tls allocation at thread creation and dlopen"
  moved to 2.24.

* Add tunables framework: moved to desirable.

It means in practice that the tunables framework will have until next Feb 6th
to get in a good shape and testing for inclusion.  I plan to review in following
days I would like to ask the other reviews to so as well.

The next Feb 6 is also the final deadline freeze date, so I won't expect nothing
but critical CVE to being pushed.

Comments or objections?