From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 3C4943858D28 for ; Wed, 9 Feb 2022 14:57:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3C4943858D28 Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-479-R-nBXNdhNoSxJbQzxT_LVw-1; Wed, 09 Feb 2022 09:57:45 -0500 X-MC-Unique: R-nBXNdhNoSxJbQzxT_LVw-1 Received: by mail-qk1-f199.google.com with SMTP id u9-20020ae9c009000000b0049ae89c924aso1566791qkk.9 for ; Wed, 09 Feb 2022 06:57:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:from:subject:organization :content-transfer-encoding; bh=AMPT5YBGPoSHxjZisHHRBj5sE0Y/GxnchHXMfaR7oCM=; b=woMOIil0QycXqE3KLku9puCZLLdnmdbsF4dY9Kv7E6LNuketOozoIrGKAcjmUVRKbd 86LfvmkWZj9TYC9OkpYLNQN0MFoJGDCKNtUX8TP5QJW2pJkDUKZMJssbtzxqqylub4at nug0y7cNHvpknD2YgYQlPjtXEgcyNMWRi5NVKMlbZvcIQNHLRWVXrcTJZIDHatS+UrAw 6gYBacW1kBq3l/0rOQ67Im+FQItZmWbwSV3O0tNnJwTZ7xXIgtXDWIbnVMbg8VSgzzXi 0XUyDwUEtHGwGBF2obxCxzId8b3cYTo/ei9myBkyDf9VN8mhqye+KAD9UclxAyhDvtl1 dRWA== X-Gm-Message-State: AOAM5336tEDOoG4KJOk6ow1NO/3734nxJJxmycEP/01AFBB3tQz4DQSU 3EfUeBJDtknsj3HH7k154wSv/TsJJ8XAory57WGlIO1tOI7UPwk73WgZtquPkqfssg8J1P1XToN K6AIGEiOyDpC24NPW9Jnd9BIYlb9lmu0+kp7Bm7BL4uPM/Iuf7iEnmjwX5lAP2qRsENC5Gw== X-Received: by 2002:ac8:44c4:: with SMTP id b4mr1556503qto.516.1644418664964; Wed, 09 Feb 2022 06:57:44 -0800 (PST) X-Google-Smtp-Source: ABdhPJyLAFU0yxtFrwUU79MxbkpbYKJBT2JqEwcFJUw8nhZgzhetTl4B7TewS0rY/MjRylSkPegPUg== X-Received: by 2002:ac8:44c4:: with SMTP id b4mr1556490qto.516.1644418664615; Wed, 09 Feb 2022 06:57:44 -0800 (PST) Received: from [192.168.0.241] (135-23-175-80.cpe.pppoe.ca. [135.23.175.80]) by smtp.gmail.com with ESMTPSA id h11sm573783qkp.89.2022.02.09.06.57.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Feb 2022 06:57:43 -0800 (PST) Message-ID: Date: Wed, 9 Feb 2022 09:57:42 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 To: libc-alpha From: Carlos O'Donell Subject: Retrospective on glibc 2.34 and glibc 2.35 release. Organization: Red Hat X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham 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: Wed, 09 Feb 2022 14:57:48 -0000 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. Thoughts? -- Cheers, Carlos.