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

["Carlos O'Donell" <carlos at redhat dot com>]

On 06/21/2013 10:00 PM, Roland McGrath wrote:
> 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.

Agreed.

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

I agree that the end of the month is a good place for a hard deadline.

I don't want to go any further either.

I've carved out my entire week to look at last minute issues with
Intel TSX LE.

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

Agreed. This problem is as old as time.

Cheers,
Carlos.