Re: glibc 2.18 freeze status v2 - One more week.

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

That sounds sensible to me.  But I'll note as a general matter that if
we really intend to keep to time-based releases, then at some point we
have to choose a cut-off date at which we decide that a pending
"want-to-have" feature is either adequately baked as is or just isn't
and we punt it to the next cycle.  Consensus for the date and for each
feature's go/no-go decision should probably be substantially weighted
by the feelings of the particular cycle's release manager, that being
the person on whom the extra leg-work of a less-baked-than-we-thought
feature needing lots of tweaks and fixes on the release branch (and
likely a generally higher churn rate for the whole maintained life of
the branch) will fall.

For me personally, the lock elision work is a "nice-to-have" and not a
real strong one at that, and it seems likely to be a close scramble to
hash it out next week.  So I find it easy to say that the end of the
month should be a fairly stiff cut-off and that the decision to punt
if not pretty darn stabilized should be the default.  It's also the
case that the week after next has US holidays (for me, a four day
weekend 4th-7th where I probably won't read this mailbox at all) and
the following weekend is Cauldron (and I imagine some of us travelling
beforehand to be there, though I'll be there and don't have to
travel), so after next week productivity and efficiency of
coordination among folks is liable to dip for a while.  With all that
in mind, three days before then seems like a good time for a deadline.

But clearly others are far more invested in this work and feel much
more urgency than I.  I won't especially argue against delaying
further to finish hashing out the prerequisite issues for lock elision
stuff, if on the 1st it's still not fully settled but people are gung
ho.  I just make the point to suggest some more generically objective
perspective on notions of feature urgency and creeping slip of
supposed time-based releases.


Thanks,
Roland