From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id 7F8EB3858D38 for ; Sat, 4 Mar 2023 17:52:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7F8EB3858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org From: "Andreas K. Huettel" To: Michael Hudson-Doyle , libc-alpha@sourceware.org Cc: libc-alpha , Sam James , Simon Chopin , Carlos O'Donell Subject: Re: release branch policy and distributions Date: Sat, 04 Mar 2023 18:52:42 +0100 Message-ID: <13643081.RDIVbhacDa@pinacolada> Organization: Gentoo Linux In-Reply-To: <40ee09cc-cfa1-4aac-d51e-120f0dbaccd9@redhat.com> References: <40ee09cc-cfa1-4aac-d51e-120f0dbaccd9@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart13213415.dW097sEU6C"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --nextPart13213415.dW097sEU6C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; protected-headers="v1" From: "Andreas K. Huettel" Subject: Re: release branch policy and distributions Date: Sat, 04 Mar 2023 18:52:42 +0100 Message-ID: <13643081.RDIVbhacDa@pinacolada> Organization: Gentoo Linux In-Reply-To: <40ee09cc-cfa1-4aac-d51e-120f0dbaccd9@redhat.com> MIME-Version: 1.0 Hi all,=20 > The outcome I want is for there to be fewer defects in the development br= anch, > and by proxy fewer defects in the release branch. >=20 > (1) Do we have evidence of an increased rate of defects? I can't contribute more than anecdotal evidence myself since I do not do=20 regular builds (see below).=20 I myself hit (from memory) a bug in the Intel optimizations once, which was rather quickly fixed with two more backported commits. (The symptom was failing tests on my own machine, so found before installat= ion and no real harm done.) > (2) What is your distro policy for updating from the rolling release bran= ch? >=20 > While upstream gives a policy, what is your own policy? =46or Gentoo, nothing automated.=20 When I become aware of an important fix, someone pokes me or I otherwise feel like it I cherry-pick new commits from the release branch onto our Gentoo branch [1] and spin a new tarball (a tag here [1]). Usually this=20 catches up with all new additions from release/2.xx/master. This then becomes an "unkeyworded" ebuild in the Gentoo repository, meaning noone gets it unless explicitly requested. After some testing by me and other Gentoo developers, it enters Gentoo "testing/unstable". In case of new releases (i.e. first 2.37 introduction) also a tinderbox run will typically be done (mass test build with new glibc, which in itself becomes some sort of runtime testing too). Gentoo stable is most of the times one release back [2]. Bugzilla is monitored closely before "stabilization", which typically jumps from=20 an "advanced" 2.xx revision to an "advanced" 2.xy revision, say from 2.35-r11 to 2.36-r5. This somewhat assumes that during the lifetime of the release branch its state continuously improves (e.g., bug fixes only). [1] https://gitweb.gentoo.org/fork/glibc.git/ [2] http://packages.gentoo.org/packages/sys-libs/glibc > (3) How does delaying backports impact our outcome? Much of the quality control for Gentoo stable is effectively the feedback from Gentoo unstable/testing. Given that we unleash only released versions on our userbase, code that has= been in a release naturally gets a lot more testing. (Both build testing with all combinations of flags and architectures and runtime testing.) Since installation of the package fails when the testsuite fails, not many of our users enable the test phase (and we also do not recommend that in ge= neral). Installing a git master version of glibc to your system is trivial in Gento= o. However, if you do it to your main system you'll be told that you're insane= =2E :) So this is mostly for test containers. It's not easily possible right now but a similar mechanism could be impleme= nted for release branches. > One way is that we use this extra time to do additional testing that disc= overs > defects, and then we work with the machine maintainer, IHVs, etc, and cor= rect > the defects. >=20 > 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. The testsuite of glibc catches a lot of potential problems. It'll never beat real-world usage though. > How could Canonical, Gentoo or Linaro support additional upstream testing? The Gentoo-specific part is actually very small, right now 9 patches [3]:=20 * 5 of which are Adhemerval's readdir patchset * 1 is the ia64-specific fix from=20 https://sourceware.org/pipermail/libc-alpha/2020-May/114028.html (which turned out to be not ideal, but a better solution never material= ized) * 2 are small Gentoo-specific adaptions * 1 hardenes the conformance test suite against CC=3D"gcc -O2" by adding -O= 0 there https://bugs.gentoo.org/659030#c6 [3] https://gitweb.gentoo.org/proj/toolchain/glibc-patches.git/tree/9999 > Can we work together to turn on more distro-specific pre-commit CI testin= g? > 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). I certainly have no objections to additional pre- or post-commit CI testing. That said, we don't really have the means or infrastructure to do that freq= uent mass rebuilds and runtime testing. And I tend to be more worried about random unexpected things popping up that are not caught by the testsuite. Not because they happen frequently, they clearly don't, and on the whole I am really very happy about the code quali= ty and backport discipline. Because of the wide potential impact. Best, Andreas =2D-=20 Andreas K. H=FCttel dilfridge@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) --nextPart13213415.dW097sEU6C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQKTBAABCgB9FiEE/Rnm0xsZLuTcY+rT3CsWIV7VQSoFAmQDhWpfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZE MTlFNkQzMUIxOTJFRTREQzYzRUFEM0RDMkIxNjIxNUVENTQxMkEACgkQ3CsWIV7V QSqGzg//VVpPlUVBtqz8ZCLq/3bpSLPEZCPhKFvNnizo13mjwtYsUemk66Zmi1Qi 7dH3hGYvNPTGvgEn1EakhiG7w5inc30dJLwKWE2wobRF32993J6ukS0FxnSx5mcj xDdkDAEMQWrUigPJCWECl32Brs9+0xK9C8ivz5uAwI+UdQIfTEM07U+LzWVgX3hS ZS/JeBcTn4lv5P/wJiu6fGkBY0I9oAeIs0PDWsSmqk683dHlHkYVI05jwtImfOoo uUmZ9JxI24lzWn4VQJxnKHMrNLl+l5HsTsBfz0DmDPEcVbS8Jo8MHpOxP+yjeSKW s1cdI9j18TPCG+gUPoIqhIom/eoq+OlBe7ipmPbn9q8gq2jp7qd5ZsGl+nAcfyoi +uNWOJWXK49A8E4MKlrxWrv8zpKvqvFeHwMSfCXmTkP8e2QTO36AT6ZzBBIdAcAi lteh911mF9yy2NAgJT54mSHHV7av4MceYvVoPqr8zdvvx98oWnFvVkB2xjdb8OCF UwWdZ+nRd1rsPA2sAipaOTNExg2s0R/0N6oE+zs70n08uNTZovoLpk871dQLOxYP Rg4wt2MyZqRar0SpHbE2gI6rsFNYf1+jhfck6fZRWm/I9iHoQZt2w3BZgm31vJGA ip+rSdeTGaPbtKITihmdVmmAUTlfUJ1CwEsxxBnCTTXqvjJ50bo= =Noo2 -----END PGP SIGNATURE----- --nextPart13213415.dW097sEU6C--