From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id 9581C3858C39 for ; Fri, 17 Feb 2023 12:24:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9581C3858C39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oi1-x22c.google.com with SMTP id bl6so920583oib.11 for ; Fri, 17 Feb 2023 04:24:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=hhld4Tv85tqK1cBKenqeez9tj96JYvcx2lP46pZsubE=; b=RZXCWCta6jMu9/uWEpL2/zJfaM7DZshcItz/X9JpCoakvonZ+KJT0zS2DhKnKSkYqA bSEX3R5CnJsGwkEyWQsC+m+Ao5YErnfVlSh6jlMnlyoNp6cgwd6Y9cnoeOiJBD877ali ppzJ6uTy9+VUuNKKhcNhufCpncDOUYttAr8ksLmma4BQVFATKaiJcjY4hoC6F9NwopQv RyLD2ML1ysagu9Bl7GHhSEKHQe4xV+FYqXUXpAJB4SJkjufkAdZDVxMa7DkBSgFtTOfD uGBn0p/mIOOjyGvYRglunLBMb/oDf0k1yUTTGRstieNHaotuHtAu8eTmMd16R5qppjTl fzFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hhld4Tv85tqK1cBKenqeez9tj96JYvcx2lP46pZsubE=; b=CBQmTizjMoRl+Kj+KhjFVEjPHSRvBc40H7qL3CyhPkYOmPuRQ4cIwwwlIhjfoD5Iw3 F6dnM2O9H2a3UZKeVm49oBLCtGC0ey9GiQdNqQRYXJQsNLeV4ch7p+YUPdA71YTii95g y6ODqN2mvFnh6pATOgtxDc5u9uc+Sn9gEbH0b9rd9ToggCbA6jRXOGVbSjvuEsb8eFYg vgXkJ1ztjGBdFt8yF/udA9/onlVoZMIX74zybiSVWap7c4g843204G10mX3glJDcoUWb gUEZauCsBxtJfnr7geFzgEMch72ATSYRknTr8u4mnHKGw03o0IQGCycOR9YtOXbAHYxr +bbQ== X-Gm-Message-State: AO0yUKXptI0eSzd5aIyEcZw8dp6vfBG+P/T5FWu5T4y7j2iOK3x3viq9 6CqFPGEMguG4qpuGUAgRPE6ppq6GwZnBUVD+5zQ= X-Google-Smtp-Source: AK7set8NCZ23XrZv/m24ul/foOl73spiLEzC4Jnl1C3wjy5xkONbTs1GoCIGer4/RJ/GKQlbVmBqRw== X-Received: by 2002:a54:4717:0:b0:37f:b2dd:72e with SMTP id k23-20020a544717000000b0037fb2dd072emr710712oik.5.1676636678654; Fri, 17 Feb 2023 04:24:38 -0800 (PST) Received: from ?IPV6:2804:1b3:a7c3:3a5:d16:437b:3b74:d999? ([2804:1b3:a7c3:3a5:d16:437b:3b74:d999]) by smtp.gmail.com with ESMTPSA id n127-20020acaef85000000b00364e8f85c08sm1670033oih.21.2023.02.17.04.24.37 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Feb 2023 04:24:37 -0800 (PST) Message-ID: <6280213a-8f6a-4613-c69f-ea40dd67ffbf@linaro.org> Date: Fri, 17 Feb 2023 09:24:35 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Subject: Re: release branch policy and distributions Content-Language: en-US To: libc-alpha@sourceware.org References: From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,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: On 16/02/23 19:57, Michael Hudson-Doyle via Libc-alpha wrote: > 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 am not very found of performance backports either, and I think fair to setup a buffer time before such backports are added on release branches. I would prefer to be even more conservative and set that only performance improvement from a previous release are eligible to backport, it will give even more time for users to verify there is no regression on multiple different hardwares (which is not readily available for glibc developers). > > 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. >> >>