This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.23 --- Hard freeze starting
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 20 Jan 2016 14:56:25 -0800 (PST)
- Subject: Re: glibc 2.23 --- Hard freeze starting
- Authentication-results: sourceware.org; auth=none
- References: <569D4A42 dot 7030006 at linaro dot org>
> 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.