Re: glibc 2.23 --- Hard freeze starting

[Roland McGrath <roland at hack dot frob dot com>]

> 1. Add tunables framework: Siddhesh sent a v2 patchset 01/16 without
>    further comments.

This is nice to have but I see no reason it should be a hard blocker.

> 2. Add strlcpy/strlcat: from latest messages I noted Paul has asked to
>    delay it to 2.24 for further discussions.

I concur with punting this from 2.23.  There is lack of consensus on key
issues, and I don't see any reason to hurry on something that people have
been asking about for many years already.


As to the general process questions, I see these categories of changes in
freezy times:

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 I can't really imagine how it would be so
   important as to qualify as an actual blocker.  The only things that
   really come to mind are cases of pathological performance in some use
   case that matters, or nontrivial performance regressions from a past
   release.  New functions should pretty much never qualify.  (A
   plausible exception is something 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 desireable
   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.  This doesn't mean that a release should necessarily be
   delayed when these are not finished (they're not blockers).  It just
   means that we should make serious efforts to get them finished during
   the freeze period rather than punting them off hand just because of
   the time-based release schedule.  If they're not done enough to go in
   and be considered stable by the really-really-hard freeze time, then
   they don't delay the freeze or the release.

3. Nice to have.  These are changes that are desireable 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.  So if such a
   change is ready during a freezy period and consensus is that its risk
   is quite low, then it can go in.  But the distinction between
   specifically "nice to have" for this particular release and
   "generally good change" (something that would go in but without any
   special priority) is pretty small.


Among the current list of items:

* The tunables framework has no plausible rationale as a blocker.  I'm
  not sure what the rationale is for putting it in the "important"
  category either, but that is much more open to debate and different
  kinds of rationales.

* BZ#19329 is plausible off hand as a blocker or important because it's
  a user-visible bug.  But consensus appears to be that it's
  sufficiently complicated, and users seeing it bite is sufficiently
  rare, that any change in this area will be risky and should not be
  rushed--and it's not a regression introduced in any recent release, so
  it's just a bug like any other.


There seems to have been some tendency for people to attempt to declare
something a release blocker for no reason other than that they hope
people will work harder on it sooner than they otherwise were, they feel
it has been neglected for too long, etc.  That alone is not a valid
rationale for either release blocker or "important feature".  The
release process is not the way we decide priorities and resource
allocation.