Re: The 2.20 release code freeze is very near

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

> The code freeze for the glibc-2.20 release was scheduled for July 1st.
> I realise there are still a few things that have appeared on the mailing
> list that are desirable for this release as listed on the wiki page [1].
> 
> So this is not a freeze, but it should be getting quite cold...
> Consider whether your changes can wait until 2.21.

Another thing to consider is that (according to his autoresponder), Joseph
is unavailable until July 15th.  Shortly after that, it's Cauldron and
several of us will be travelling and so on.  (Myself, I will be travelling
after the 16th, then at Cauldron, and then on vacation the following week,
until the 28th).

People being gone certainly doesn't mean we should have more destabilizing
changes than we would if everyone were around.  But it does mean that the
testing by machine maintainers, maintainer review of small patches, and so
forth, will be delayed or slowed down this month.

I don't think we should get upset about delays, really.  The notion of
time-based releases is to make sure we have them frequently enough, not
because we have deadlines.  It's more important that we have a release
of high quality and are confident of the testing it's received than that
it happen in a given month rather than the next.

I think it makes sense to say that we are now in a "slushy freeze".
That is, only the things on the list, and moderately straightforward
fixes (or any fix for a regression from 2.19), and other cleanup changes
that reduce or consolidate code without changing a lot.  (I'm thinking
of the sort of cleanups I've been doing lately, which I can test to
confirm that they don't change the generated code at all or only barely.
Those seem safer than anything where the code really changes so that we
are relying on dynamic runtime tests to ensure nothing goes wrong.)

When the things on the list are done (or all but) and fixes awaiting
review are cleared out, then we can be in real freeze.

> Can I also get a status on these so I can track where we are:
> 1) -Wundef cleanup

Siddhesh and Andreas mentioned many outstanding cases.  Nobody has
mentioned IS_IN_*/NOT_IN_*, which I also see.  I have some vague notions
of attacking the IS_IN*/NOT_IN_* cases in a holistic way, but I have not
put actual effort into it.

> 2) De-add-on-ification of NPTL

This is ready to go in except for two lagging machine maintainers, and
nobody having reviewed/tested the main final changes.  The two lagging
machines are hppa and ia64.  Carlos said he would deal with hppa RSN but
still hasn't.  Mike (ia64 maintainer) is on vacation and might not be heard
from until the end of July.

I had said last week that I hoped to commit the branch this week.  But
I'll be taking a long weekend starting tomorrow for the US holiday and
don't intend to pay a lot of attention until Monday (when it's possible
I'll be kidnapped by my county to be on a jury).  So now I'm hoping we
can get it finished up the middle of next week.

Carlos just needs to get on the stick, or else hppa can be broken IMHO.
For ia64, I'm sure everybody will be happy if anybody who feels
competent to review and test ia64 changes does so.  rth has indicated he
might be able to do it, but he's not obliged to.

I have rebased the roland/nptl branch frequently and it should be in
good shape.  I tested x86 (both) and ARM, but haven't repeated the
testing lately.  (Between Dave and myself, we've pretty well tested
SPARC too.)  The final stages affect every machine and will need testing
for every machine.  They're intended not to change any compiled code
(except maybe assertion file names and line numbers, and possibly object
files reordered in the DSO links).  So people can test the branch by
comparing object files of immediate before and after builds, rather than
having to rely on the test suite and debugging individual regressions
dynamically.  But so far people have not been jumping up to do it, so
I'm not sure anyone will without just forcing them by committing.

So here's my tentative plan: I hope Carlos will deal with hppa between
now and Tuesday.  I hope rth or someone will deal with ia64 soon.
Whether they do or not, I'll repost the roland/nptl branch changes next
week (after fresh x86 and ARM testing).  Then, unless someone has
concrete review feedback or does testing that turns up problems and
those are not all resolved quickly, I'll commit by the end of the week.
If hppa and/or ia64 are still lagging, their builds will almost
certainly be broken and that's their problem.  If other machines haven't
even attempted the testing, then their builds might be broken (though I
hope not) and if so that's their problem.

Opinions?


Thanks,
Roland