Re: glibc 2.23 --- Hard freeze starting

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

On 20-01-2016 20:56, Roland McGrath wrote:
>> 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.

Agreed, I will remove it from blocker issues.

> 
>> 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.

Agreed, although Florian already has moved it to next release.

> 
> 
> 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.)

Agreed.

> 
> 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.

Agreed, the question is if we should or not only consider patches that has
been already send and/or reviewed before the froze schedule.  My problem w
ith latest changes is we need to set a really hard freeze for such changes 
as well (say first two weeks of hard freeze) because not every architecture
maintainer/tests regularly check or have hardware availability based on the
timeframe the important feature is pushed to check for regressions.    

> 
> 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.

Agreed.
> 
> 
> 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.
> 

Agreed.

> * 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.
> 

Agreed.

> 
> 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.
> 

I also would like to add these observations in release procedures in wiki
page. Any objections?