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.133.124]) by sourceware.org (Postfix) with ESMTPS id 09FEE3858D37 for ; Thu, 2 Mar 2023 18:04:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 09FEE3858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677780256; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DH/S4M38EWW4iQnNB7TU1pDVhApnZ/tvOt9Ap4mz9d0=; b=i4toYdL3CkHJe067kIyIUGayq/EK12wd1uSRXOq323t/4Lwtq2ZWv/xTx7H8bfYgQu3n/2 za9He8Qag51NcJsV9rjBsPEsXsoIXnLUPlaGR4BgtJKYYKbtTqqSyJOw31yk2nrfe75eH+ jkbZaDLSyb84eJGT2h/HAGNTpWGNZ5s= Received: from mail-io1-f69.google.com (mail-io1-f69.google.com [209.85.166.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-202-nRgIT9POOoKHXgL2n-wUHg-1; Thu, 02 Mar 2023 13:04:13 -0500 X-MC-Unique: nRgIT9POOoKHXgL2n-wUHg-1 Received: by mail-io1-f69.google.com with SMTP id v10-20020a056602058a00b007076e06ba3dso11141854iox.20 for ; Thu, 02 Mar 2023 10:04:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677780252; h=content-transfer-encoding:in-reply-to:organization:from:references :cc: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=DH/S4M38EWW4iQnNB7TU1pDVhApnZ/tvOt9Ap4mz9d0=; b=aVen9IJZPtumi1NT7qi318RRTpPe7EVvUnOFVLppOgH8OIa5fJOBoEQ3oTJZ0UYAXe WC7jk+EaxbRrpG5QlSMA3tygqP4Ndq+GJ2HNn6bCH6FyfYeWcYdPXxe9Y9+yCrnA+2Z8 1g+a/Quz58xBjTn3fHo87nzusSH20DOlsHiHo8hkTZGPZKqSYEEJP4lsw0TKitkDauxD DimOirAwgPcvaa/0/92wPTKFEjvC3PAaDXKtgChzO+uEtiacbquEnLdbm10vMuuvY9t1 Kp47eXVibFmwDcHv+UPZQHP2HOq5leZCeLagY1rMxEnZLrxHDlYoHoJqtLRjoojTJHpV ARBA== X-Gm-Message-State: AO0yUKWljMr6zCL73n9O5vNoqUczwPzMX6ZIXMDDs8Ta2LkjmRqIh6yh FqZ+It6FLaJ7yJ0KJBj+8RVvQifR6HjW7wfIbnnScJ2Y5/89KxdxWn2SLIXQVPSaRJydbOYQlkd lj3A98XO4e3z0fRp621+q X-Received: by 2002:a05:6e02:156d:b0:315:7354:955c with SMTP id k13-20020a056e02156d00b003157354955cmr9167581ilu.10.1677780252152; Thu, 02 Mar 2023 10:04:12 -0800 (PST) X-Google-Smtp-Source: AK7set+e3vuNLwE6caUjI3OWPpMGJzVUdbdOgRNRjrnSHdKEKzhbDZiwFQ8uPK+TjPygILyPb0zxhQ== X-Received: by 2002:a05:6e02:156d:b0:315:7354:955c with SMTP id k13-20020a056e02156d00b003157354955cmr9167570ilu.10.1677780251908; Thu, 02 Mar 2023 10:04:11 -0800 (PST) Received: from [192.168.0.241] ([198.48.244.52]) by smtp.gmail.com with ESMTPSA id dj15-20020a0566384b8f00b003c86e420f9fsm46441jab.100.2023.03.02.10.04.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Mar 2023 10:04:11 -0800 (PST) Message-ID: <40ee09cc-cfa1-4aac-d51e-120f0dbaccd9@redhat.com> Date: Thu, 2 Mar 2023 13:04:10 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: release branch policy and distributions To: Michael Hudson-Doyle Cc: libc-alpha , Sam James , Simon Chopin References: From: Carlos O'Donell Organization: Red Hat In-Reply-To: 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=-6.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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 2/16/23 17:57, Michael Hudson-Doyle wrote: > 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. Michael, Andreas, Adhemerval, Thank you all for raising this. I want to talk about outcomes. The outcome I want is for there to be fewer defects in the development branch, and by proxy fewer defects in the release branch. (1) Do we have evidence of an increased rate of defects? I know we have some anecdotal evidence that we recently had defects in the rolling release branches. Have we collected that evidence to determine what kind of action is required? Do we have a gap in our hardware or testing that needs to be improved? A gap here could be that we need to setup x86_64 pre-commit CI with an AVX512 system to test all the IFUNCs (which may catch nothing if the tests are missing). Another gap here could be that we need to setup pre-commit CI to rebuild certain packages under the modified glibc (similar to Fedora Rawhide CI). (2) What is your distro policy for updating from the rolling release branch? While upstream gives a policy, what is your own policy? Example: Fedora Rawhide CI rebuilds a number of packages using the new glibc we sync weekly, and we review the rebuild failures and their testsuite results before putting the new glibc into Rawhide (or stable Fedora releases). For example, rebuilding lua and running their testsuite, particularly the string testsuite is good at detecting further string-related optimization defects. (3) How does delaying backports impact our outcome? One way is that we use this extra time to do additional testing that discovers defects, and then we work with the machine maintainer, IHVs, etc, and correct the defects. This means that the action we want to take is not delaying, but some kind of increase in testing. In fact delaying may solve nothing if additional validation and verification is not carried out in that delay period. My opinion is that delaying alone is not an outcome changing activity, and as a steward for the project I do not want to delay code from reach our users unless we can show that delay allowed the users to capture some value e.g. higher stability. How could Canonical, Gentoo or Linaro support additional upstream testing? Can we work together to turn on more distro-specific pre-commit CI testing? We have patchwork, it has a REST API, and we can submit test results via that API, like we do today for i686 test results (Fedora Rawhide-based). -- Cheers, Carlos.