This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.28 is in slushy freeze.
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- Cc: <libc-alpha at sourceware dot org>, Carlos O'Donell <carlos at redhat dot com>, Paul Eggert <eggert at cs dot ucla dot edu>
- Date: Tue, 17 Jul 2018 21:53:01 +0000
- Subject: Re: glibc 2.28 is in slushy freeze.
- References: <b68fba8c-8bbd-2d02-2307-cbf3faefadc7@redhat.com> <20180706123514.7ae52153@athena>
On Fri, 6 Jul 2018, Albert ARIBAUD wrote:
> Depending on how gnulib syncs on glibc, I /might/ request that at least
> the very first patch from the Y2038 series (the one which defines
> __time64_t) be pulled in the upcoming glibc release so that I can move
> forward with Paul Eggert's request that at least part of the Y2038
> glibc patches go through gnulib first.
I don't think it makes any sense for this to be a freeze exception. It's
not a user-visible feature (it's a type in the implementation namespace)
so it doesn't matter in the least whether it's present in 2.28 or not, and
so because it doesn't provide any benefit to the release, it's safest to
keep it out.
Given there are plenty of design discussions around the proposed 64-bit
time patches and it seems likely various aspects of the patch design will
change in future versions, it's a lot better for the first patches to go
in at the *start* of a release cycle - when there's plenty of time for
subsequent reworking as designs change in the course of implementation and
review - than at the end of a release cycle, when you risk, at the very
least, confusing people who look at the 2.28 release in future with having
something there that is significantly different from both the final design
and from previous releases.
--
Joseph S. Myers
joseph@codesourcery.com