From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cyan.elm.relay.mailchannels.net (cyan.elm.relay.mailchannels.net [23.83.212.47]) by sourceware.org (Postfix) with ESMTPS id 1A9D93858D1E for ; Thu, 10 Feb 2022 06:29:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1A9D93858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id DE2EF6C014F; Thu, 10 Feb 2022 06:29:02 +0000 (UTC) Received: from pdx1-sub0-mail-a306.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 75F666C12BE; Thu, 10 Feb 2022 06:29:02 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from pdx1-sub0-mail-a306.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.103.158.127 (trex/6.4.3); Thu, 10 Feb 2022 06:29:02 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Skirt-Bubble: 4f9395d04f78a4b2_1644474542703_4176838908 X-MC-Loop-Signature: 1644474542703:2439062346 X-MC-Ingress-Time: 1644474542703 Received: from [192.168.196.116] (unknown [106.220.173.52]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a306.dreamhost.com (Postfix) with ESMTPSA id 4JvRfN732Cznh; Wed, 9 Feb 2022 22:29:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gotplt.org; s=gotplt.org; t=1644474542; bh=KGR6g+LOdrHKbuO4EhBrdsye/3s=; h=Date:Subject:To:From:Content-Type:Content-Transfer-Encoding; b=inApdaQgAJayi8HBeiHGD2Msaq8GAqd9lpNCjsAgOX/U5loYi4EYyhStUZpI6/JFO /cChJcQ4xjDpI1HtjTaEO4OLy+yCgj2e5ppLFcWRWpOASSI1o1bXRj2qtkjovhHvCd WaYZmUbZMflL3gRVZH/TdUC42VpfsdyWGZJO6yc4= Message-ID: Date: Thu, 10 Feb 2022 11:58:55 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: Retrospective on glibc 2.34 and glibc 2.35 release. Content-Language: en-US To: Carlos O'Donell , libc-alpha References: From: Siddhesh Poyarekar In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3029.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2022 06:29:06 -0000 On 09/02/2022 20:27, Carlos O'Donell via Libc-alpha wrote: > Community, > > I was the release manager for 2.34 and 2.35, and in retrospect I have > played the hard ABI deadline too loose for my own liking, and I think > this causes additional stress and work at the last minute that doesn't > help the project. > > If I think about improving the release process it is to come back to > a harder ABI freeze deadline within the first week of the freeze. > That is to say that it looks like this: > > 1st week > - Freeze ABI. > - Review outstanding patches that change ABI that we want in the release. > - Be critical about which can be resolved within the 1st week. > - Move all others that need more time to the next release. > > As RM I ran ABI changes very late into 2.34 and 2.35, and while I'm happy > with the results of the release, I'm not happy with the process. I consider > it my own failure as RM for not hardening that release sooner. The time boxed > release for glibc supports downstreams that have aligned their release windows > against our ABI changes, and last minute ABI changes are not good for anyone. > > In order to support these ABI changes I wonder if we don't need a specific > window within the release like "Month 1: ABI" where we focus on this theme > of getting new ABIs into the first month of development? There is a similarity > here with respect to gcc's staged development. I concur with Joseph; the process as we defined it is not broken, we were only lax in implementing it. You're not the sole person to blame either IMO; we share blame because all of us let it slide for various reasons. I would normally have called you out for letting the freeze slip but I'm a hypocrite ;) I was glad that it slid for 2.34 because it allowed me to drop malloc hooks and similarly we got some needed ABI changes in at the last moment in 2.35 and so far it doesn't look like we had any fallout from it. We just need to make sure that we put a hard freeze on approving ABI changes beyond the freeze deadline and then as Joseph suggested, consider backing out ABI changes that continue to be broken during the last couple of weeks of the freeze. The one concern I have about the freeze period though is that once a year it descends on us during the year-end holidays. Getting reviews during that period has always been hard, which means that the freeze is implicitly a couple of weeks earlier for anyone who doesn't have enough leverage within the community to get reviews for their patches. I wonder if there's scope for a 2 week shift in our schedule so that we freeze on 15th Jan and 15th Jul and release on 15th Feb and 15th Aug. Thanks, Siddhesh