From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65742 invoked by alias); 17 Jul 2018 21:53:10 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 65725 invoked by uid 89); 17 Jul 2018 21:53:09 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=pulled, H*Ad:D*ucla.edu, HTo:D*fr, syncs X-HELO: relay1.mentorg.com Date: Tue, 17 Jul 2018 21:53:00 -0000 From: Joseph Myers To: Albert ARIBAUD CC: , Carlos O'Donell , Paul Eggert Subject: Re: glibc 2.28 is in slushy freeze. In-Reply-To: <20180706123514.7ae52153@athena> Message-ID: References: <20180706123514.7ae52153@athena> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2018-07/txt/msg00510.txt.bz2 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