From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-relay-internal-1.canonical.com (smtp-relay-internal-1.canonical.com [185.125.188.123]) by sourceware.org (Postfix) with ESMTPS id A9E063858D33 for ; Thu, 16 Feb 2023 22:57:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A9E063858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=canonical.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=canonical.com Received: from mail-pl1-f198.google.com (mail-pl1-f198.google.com [209.85.214.198]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 261E53F206 for ; Thu, 16 Feb 2023 22:57:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1676588234; bh=VEp17fJQSIKOV6xy78T9qY9uASgEJsdema1l1PsIgAs=; h=MIME-Version:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=RDjoRfiRahIBLHR29l6Pmz2FH/mS8UMcTYxcTRbzhsENmekSwLV4Td4tri/+kt+Rv gvlzGMd8Sj4+dHm11hi8lvAc6SxqbnN9xVv+uTuRe9Brx1Pudx0NQcGZ249Mfr0BCl fwhdD14J6nvurrsLXFZUCAesk9NinudbULmSIyF5DOpdY612EYP0HAUGJChHKSU6EN nCuNFWSUMx5GIjRWf7zz1bxXpwn/0BBVEBMJs79sDpX5CdYCv4iiiIjdhgt+haPY3H VxSRjJVvQ+M3PwaWtjIFFKelG4vMt1pWpAZr1/JQcul6133WzyE30VxIFjJjoZTow5 IBliws3EHXvmg== Received: by mail-pl1-f198.google.com with SMTP id jb7-20020a170903258700b0019af23e69dcso1531992plb.19 for ; Thu, 16 Feb 2023 14:57:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=VEp17fJQSIKOV6xy78T9qY9uASgEJsdema1l1PsIgAs=; b=K3JSQljCBAmROPsFq28ipJKUzopy9PbYMRnZns62MTjfxRIGEPlRbXTi/ME/ijxb4T WQ6ONLiP4bcE+s9bp2odZZEKHBBycGi3ut/d3pdrfItVEUCXLRDdc8YRv93SHjdTwZhh hM2gXm/Jl2iPYaOtUsb+5xijh2kvSrIlbvIDK48Tw//cwZcYOILCN3dDgo9DEt/8hx58 7kWsLSIHi1uSJ27IpcvySg4coaC5G1jyXM38FBfg1PH+2nxD7w8Lh1bOAHGbcX9Fbdxx fDs+1ho3BI5RZl1E8i5Lx/P5ope3JAew8lH8lgwrP7qNwz5JX74XpQ+m+enWjpHl6hz0 lfGw== X-Gm-Message-State: AO0yUKUrnqZqxJzzZ+0HbkV7ZvCIok0rez+fxzdd4nt0sc05OaN2EnLa hmJJICSeUCaUdq3eeZC0Du5ZfA8awNsbbMBJzN5YMmW9/NsgE5dlW1J1YBKphyEI0QcCE2LbW1e PRYnbokzJyE10/ClohcbxUR1TULc0lncn+g41mc6qc/C5AEkrPbHIFQ== X-Received: by 2002:a17:90b:1d4d:b0:233:b331:1def with SMTP id ok13-20020a17090b1d4d00b00233b3311defmr976580pjb.132.1676588232514; Thu, 16 Feb 2023 14:57:12 -0800 (PST) X-Google-Smtp-Source: AK7set8Fq9G5cRR1kWD2EJHBB1PqlXBbY1qr4UlE6T3rTIwvl/xtsgXpObCP36EQ+3AvQsnQPeMG18oZHt/8nWef0uo= X-Received: by 2002:a17:90b:1d4d:b0:233:b331:1def with SMTP id ok13-20020a17090b1d4d00b00233b3311defmr976573pjb.132.1676588232044; Thu, 16 Feb 2023 14:57:12 -0800 (PST) MIME-Version: 1.0 From: Michael Hudson-Doyle Date: Fri, 17 Feb 2023 11:57:00 +1300 Message-ID: Subject: release branch policy and distributions To: "Carlos O'Donell" Cc: libc-alpha , Sam James , Simon Chopin Content-Type: multipart/alternative; boundary="0000000000000190c505f4d91ee4" X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --0000000000000190c505f4d91ee4 Content-Type: text/plain; charset="UTF-8" I've sat on this for a while, sorry. On Thu, 2 Feb 2023 at 11:03, Carlos O'Donell via Libc-alpha < libc-alpha@sourceware.org> wrote: > Sam James (Gentoo) brought to my attention during the glibc 2.36 > release that some distributions did not know about the release/* > branches. We discussed adding more text to the release announcement > to highlight the purpose of the branches. > So speaking as one of the Ubuntu maintainers, we have historically not done a very consistent job of getting glibc updates to stable releases. I would like to get to a more consistent schedule of updating glibc in long term support releases, maybe every six months for the life of a release. I think most of the reason we haven't been good at this is resourcing (hi Simon! :-p), but... > For glibc 2.37 I've added the following text to the release announcement: > ~~~ > Distributions are encouraged to regularly pull from the release/* > branches corresponding to the release they are using. The release > branches will be updated with conservative bug fixes and new > features while retaining backwards compatibility. > ~~~ > ... I do have qualms about the definition of "conservative" here. The updates are certainly conservative wrt ABI but there has also been a trend to backport optimizations and this has occasionally led to bugs being introduced on the release branch, like https://sourceware.org/bugzilla/show_bug.cgi?id=29591. Now bugs happen and I don't want to make too much out of any particular issue and there is obvious value in getting performance improvements to users of stable distributions. But! I think there is an issue of timing: if an optimization is backported to release branches before it is included in a release, the first time it is exposed to wide usage could be via an update to users of a stable release, and that doesn't seem right. Would it be unreasonable to suggest a policy where performance improvements are not backported to release branches until say a month after they have been included in a glibc release? I realize this would add some overhead to keep track of these 'pending' backports but I personally would be happier consuming the release branches directly if there was this sort of policy. I'm open to any suggestions for specific wordsmithing here, but the > intent is to continue to encourage distribution participation in the > stable branches as we do today... starting with using them. > Well. I want to suggest more than wordsmithing I guess! Cheers, mwh The last 3 releases have seen ~700 commits backported to fix bugs > or implement ABI-neutral features (like IFUNCs). > > Thank you to everyone doing the backporting work! :-) > > I also called out everyone in the release announcement who had their > name in a Reviewed-by tag. > > Thank you to everyone doing reviews! :-) > > -- > Cheers, > Carlos. > > --0000000000000190c505f4d91ee4--