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 80B033882668 for ; Tue, 18 Jun 2024 12:38:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 80B033882668 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 80B033882668 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718714323; cv=none; b=Kc4t5a6s02B//qdIhpz2SqZJqNUIf1B384MUHfHzQ9z16YoVraafq6SNGHHtplDsZzpu22P2eWQc9gZ5tujLo2pJHmpUdC1Z/MhlkbgwaaL2A1vhPNKHz6oBNlp1EQAgJv/q7GWsRl+Nan+m947Fv9i6z576jHq3yRAHTThzZhk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718714323; c=relaxed/simple; bh=InXhEMg7ho6EbR7R2eHePrS9Cd4yJ/H94qjBRfy3sjc=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=FJHqsfSG8/llowqS5+yALJzkhtwqU9VipA12xcCW1GS2e8Qu2GdTVj6bor0H5oRf4wxgWt/BCwhD2dspqU6vDxFTXclk8viq1OLGPekRv0YFwa1z3XEWfSLC2+4SZgC4HdBsj+kRv4ZGX4IxNGszXdVenQ8zOv+YWHxV+JtLFjU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1718714321; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=B5Hs/SZmWVWWSCWUO9WnhyuSbrGdlRvdA1C/eVwPhs8=; b=UJ08NAzs+oeiKDfFPToqhl9Ggo2rqgsCc6fGJch31UoCQHtgyZ5KmRNB7gi/jXE1/Fwf+1 bT+oYRJLlbs6RjJqirtPn/HdvDBBcQ7/CBfhuDuJiv68HsF6PyPBwXjcUBQHCxx9dFLRcS 4854a9S/gh8masVXkpK3HsYQtlZFr8I= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-403-GABPhAkROLe4lIhfImQx0Q-1; Tue, 18 Jun 2024 08:38:39 -0400 X-MC-Unique: GABPhAkROLe4lIhfImQx0Q-1 Received: by mail-qt1-f197.google.com with SMTP id d75a77b69052e-44102aa2494so53323691cf.2 for ; Tue, 18 Jun 2024 05:38:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718714319; x=1719319119; h=content-transfer-encoding:in-reply-to:organization:autocrypt:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=B5Hs/SZmWVWWSCWUO9WnhyuSbrGdlRvdA1C/eVwPhs8=; b=XBGA0+sSq1xC0S9Ecxuk8uIPa7v4hTI9ZkVBqpiPyAnGZkLez0QhMzsdi/iFQMBU41 voZE9etr0nEn2w7pJMgxHRaLg3ESumfoiYJ+nuysV5gIUFhzekZkjflBLMdtPT6GkdbP XcCu2Yj3bHemGt7PFiOGBK3q1n1K51Xk4qOP1P/Gg7CiheiY3vW2OBQzsf9AOPgCkr7U ySW/bB3kYdbfnsDlHEb5Zh+S336L+kF3vabaLF2DXlfVOrHX4iWRccbQ5m4UokHbeqQn IIKRFX+xJZ5eYO6P7Uzykv2hUHGYSj6javqxvPbnDCgyyRh43gcV7FW7GhCxsKELXfs9 a8Aw== X-Forwarded-Encrypted: i=1; AJvYcCVATubj1eHpH531CEvpgOdaHElSblR8rh6yT0J6oq14axj21VHR/lD4SZEhJvj0x3UmetYkJZAyC1QFxgVo8Mz6GbFO5zmPKn76 X-Gm-Message-State: AOJu0YwrvBOwxnN0fSiLQEfDwWzys4nllhjBmaxznCXAaf+LzL4U0v/Q sjdb4llRmqL8eiOlqD33mUv/S6eKvMip2HOsEEoTAxMoP3/oMK4GGU3t3Oz8v2uPyV/bVflRS52 HLVD7t7484ukxWLmDl96v0J7TeQyBIFiEyN4iQBGP9oMvhZDm5uady/UQ1K/oGEZpPA== X-Received: by 2002:ac8:5885:0:b0:43a:cbd5:7599 with SMTP id d75a77b69052e-442168c0361mr110535911cf.21.1718714318968; Tue, 18 Jun 2024 05:38:38 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHLRLXRN0LDGjeiQIMM/zDl/rcprEdrJ64t42hIltwY/ah9KU8xb9M2cShAFlpCCmwxJBI34Q== X-Received: by 2002:ac8:5885:0:b0:43a:cbd5:7599 with SMTP id d75a77b69052e-442168c0361mr110535731cf.21.1718714318571; Tue, 18 Jun 2024 05:38:38 -0700 (PDT) Received: from [192.168.0.241] ([198.48.244.52]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-441ef4fdfccsm55652781cf.32.2024.06.18.05.38.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Jun 2024 05:38:37 -0700 (PDT) Message-ID: <25ee4d58-3bab-4787-9545-28191d527df6@redhat.com> Date: Tue, 18 Jun 2024 08:38:37 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: glibc release process To: "Andreas K. Huettel" , libc-alpha@sourceware.org References: <15511315.tv2OnDr8pf@pinacolada> <3833503.usQuhbGJ8B@pinacolada> From: Carlos O'Donell Autocrypt: addr=carlos@redhat.com; keydata= xsFNBFef5BoBEACvJ15QMMZh4stKHbz0rs78XsOdxuug37dumTx6ngrDCwZ61k7nHQ+uxLuo QvLSc6YJGBEfiNFbs1hvhRFNR7xJbzRYmin7kJZZ/06fH2cgTkQhN0mRBP8KsKKT+7SvvBL7 85ZfAhArWf5m5Tl0CktZ8yoG8g9dM4SgdvdSdzZUaWBVHc6TjdAb9YEQ1/jpyfHsQp+PWLuQ ZI8nZUm+I3IBDLkbbuJVQklKzpT1b8yxVSsHCyIPFRqDDUjPL5G4WnUVy529OzfrciBvHdxG sYYDV8FX7fv6V/S3eL6qmZbObivIbLD2NbeDqw6vNpr+aehEwgwNbMVuVfH1PVHJV8Qkgxg4 PqPgQC7GbIhxxYroGbLJCQ41j25M+oqCO/XW/FUu/9x0vY5w0RsZFhlmSP5lBDcaiy3SUgp3 MSTePGuxpPlLVMePxKvabSS7EErLKlrAEmDgnUYYdPqGCefA+5N9Rn2JPfP7SoQEp2pHhEyM 6Xg9x7TJ+JNuDowQCgwussmeDt2ZUeMl3s1f6/XePfTd3l8c8Yn5Fc8reRa28dFANU6oXiZf 7/h3iQXPg81BsLMJK3aA/nyajRrNxL8dHIx7BjKX0/gxpOozlUHZHl73KhAvrBRaqLrr2tIP LkKrf3d7wdz4llg4NAGIU4ERdTTne1QAwS6x2tNa9GO9tXGPawARAQABzSpDYXJsb3MgTydE b25lbGwgKFdvcmspIDxjYXJsb3NAcmVkaGF0LmNvbT7CwZUEEwEIAD8CGwMGCwkIBwMCBhUI AgkKCwQWAgMBAh4BAheAFiEEcnNUKzmWLfeymZMUFnkrTqJTQPgFAmStkMYFCQ8AA6UACgkQ FnkrTqJTQPjRTxAAnKmRztRqcP4bgMeweR3rMxDEtwQhciDybB7RgBeuZHCbY6Hmqx2so4gH 2rG9EoBJM1RZKyqztVJ2WbGPzEb4ZAW/AjmttIoN1tSdACGBbd8kPNUzJd+QsCiWGNtyaJw6 /HTLj9JRdGN16b+DzUJxww3gYZYTTkhSNUVjcrw7hzXU0Zb3z9/evXv26SDbNCqSfhAm7tNE 8ceH9H8dTcalNUPJO7bgXRhXORj9OciJrMnpPs6P4U5f/IkcVSZS1t+6R0KPWeEUXGlegTFK F1cKsSoil8mYajqAheuqbjtPHPh55dHTbG35ngjNSZyiM54PdMW5SR6zog3RAlYnuPg09g21 n9Y/ihuEZZve57Gp5wHUwNE+RKRByLlRF3Zezz6jKfjLyHqJYK8d8+vuFO1vca5OfxCEf33Y 8pLhARmHXG6mzRdji1e7Ugob2OQbvM1XWkInA+NyGeqLlE7ZnzVME5kmYVa/+qjdoqEgAqKz EdcknAZ0uud8xuAqven5X17+bBY16RZHOysOcBiGGC2E1A8Xni8cO+vH6NTCjK+OAk7UXgWB +9MFvsi7WHDJAjVlpOwuRYDWjZ8o8HhkByMAhPEzjySR9G1bzHKNOVQNFpHPTP8a5LJR6nX/ QdjKAC0bOR1TxNeK6T0h+E0iPnwWIJ6ezimzwdRl0oCbj02giyPOwU0EV5/kGgEQAKvTJke+ QSjATmz11ALKle/SSEpUwL5QOpt3xomEATcYAamww0HADfGTKdUR+aWgOK3vqu6Sicr1zbuZ jHCs2GaIgRoqh1HKVgCmaJYjizvidHluqrox6qqc9PG0bWb0f5xGQw+X2z+bEinzv4qaep1G 1OuYgvG49OpHTgZMiJq9ncHCxkD2VEJKgMywGJ4Agdl+NWVn0T7w6J+/5QmBIE8hh4NzpYfr xzWCJ9iZ3skG4zBGB4YEacc3+oeEoybc10h6tqhQNrtIiSRJH+SUJvOiNH8oMXPLAjfFVy3d 4BOgyxJhE0UhmQIQHMJxCBw81fQD10d0dcru0rAIEldEpt2UXqOr0rOALDievMF/2BKQiOA7 PbMC3/dwuNHDlClQzdjil8O7UsIgf3IMFaIbQoUEvjlgf5cm9a94gWABcfI1xadAq9vcIB5v +9fM71xDgdELnZThTd8LByrG99ExVMcG2PZYXJllVDQDZqYA1PjD9e0yHq5whJi3BrZgwDaL 5vYZEb1EMyH+BQLO3Zw/Caj8W6mooGHgNveRQ1g9FYn3NUp7UvS22Zt/KW4pCpbgkQZefxup KO6QVNwwggV44cTQ37z5onGbNPD8+2k2mmC0OEtGBkj+VH39tRk+uLOcuXlGNSVk3xOyxni0 Nk9M0GvTvPKoah9gkvL/+AofN/31ABEBAAHCwXwEGAEIACYCGwwWIQRyc1QrOZYt97KZkxQW eStOolNA+AUCZK2RDAUJDwAD8gAKCRAWeStOolNA+B0MEACVxFO++NroEQxSQ0NCWod3aDmY mYn+/08wLTeMP+ajq19FEjU0Lh/GBJl6WlSHeJ5ZJlNSiXZuiSYGMYm73DBaoZlyjbD+H9NL LwLXgtfCZYlN6Iu8JRMfk9yevVBay7Be9DkPAk565ggo0UkIjpYftiLF4TUfqnI1yO6QKXgr J2DDwlP3iiCYnWFpHdBTB2/BRurpZoRquhRGzgcdGfRDtp16Pzm/u8BjfaU5/AFRjM0IDYQ6 PaQld0uZSZ0qOn0ts6usJws5gANq4U1oWJlqL/PHOFy9mbwUnKqq0oiWrmj+Mb+Ic6m9fqB3 5CHWUhxC1QozvkuY/sTsmXnG/mnbq2oFIVcgXDsnrDHf+0GyR+TrE4AQw1Pt2utsmU67LqNB Ru/2NbSFgwPv5wWjtNwDVGSZEXlV4qJGjh8S9aaGXhRTwJsnN6qkFS1m6vHKwqnRb5Qy4XDg 7kDrhFnTWe+XSwQt+HtGvIiXcR3EScJky76YlVsWDtvZMo3NePaC3qV5HAC8d2ZL3sFqxJRu sRyjE2l6s0EEK2MUgV/dwodftECrMdGktndVTYPqLnsua/PWWKYwYrNvD8slL6VFkXDZvLLv nat9vl9mBm15b76RHvKNlRcPbB9YYCbS5fhN2ObAsVbV1c5TdBCp8lp1Fa3YK0TA+WpNZVHK vjq6hMJAjA== Organization: Red Hat In-Reply-To: <3833503.usQuhbGJ8B@pinacolada> 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.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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 6/10/24 4:49 PM, Andreas K. Huettel wrote: > Hi Carlos, > >> What is not explicit here is the goal. >> If more time is given over to additional testing, and that testing reveals defects, then >> we would have the time to correct the defects before release. >> >> So the goal is: Make a singular release tarball that includes *more* fixes for slower >> targets? > > Yes. I'm trying to combine two objectives here: > > We've run a few times into a situation where for some not-so-important > and not-so-modern target there was breakage at the moment of the release tag. > That was usually fixed very quickly, and arguably could have been fixed before > the tag, given a bit more time to look at build and runtime results. So, > > Objective A: Try to make the (exact) release better for the obscure targets. Thank you for clarifying the goals. I can support objective A. > However, I also want to avoid that we freeze for too long. One month every > half year is already a lot. So, > > Objective B: Keep the total freeze time as is. > > If you think B is unnecessary, that's fine with me. We should not *need* to freeze for a full month if we can reasonably complete machine testing in shorter time. The problem is that machine testing takes a lot of wall time. I want to decouple machine testing from the freeze cycle, but this is hard without having build bots for all of the arches that we can check on a weekly basis at least as we lead up to the release. In this ideal future we cross the line, copy the results from the buildbots and see if we're clean? We have some builders on Sourceware, https://builder.sourceware.org/buildbot/#/builders?tags=glibc but we have not done the work to keep them green, and that's the hard part. We have to commit to monitor and maintain them and if we did that then I think we could close the gap on the release? In summary: - My opinion is that we cannot meet A and B simultaneously until we implement process for post-commit CI/CD for glibc. - My position is that we increase the freeze time to 6 weeks, and that we explore post-commit CI/CD for glibc for as many arches as we can. >>> 1) Nominal freeze: not 1 month but 6 weeks before release >>> Mostly to accommodate the later changes, see below. >>> Decision on what goes still in and what goes not, review and addition >>> of final patches. >> >> I agree with (1). >> >> We should start this review ahead of the harder freeze at the 1 month mark. > >>> 2) Machine testing: 1 month before release >>> Not, as currently, effectively 2 weeks before release (after waiting for >>> the last important patches to go in) >> >> I agree with (2). > >>> 3) Branch: 2 weeks before release >>> Master is opened for development >>> Release branch only accepts obvious and simple bugfixes and/or fixes for >>> issues found during machine testing >> >> This seems to contradict implementing fixes that are issues for slower >> targets? > > Maybe I expressed myself wrong here. The main idea is, let's keep the > release branch running for two more weeks under bugfix only rules. > We have a chance to still address problems that are found during additional > machine testing. > > [One could even think of cutting x.y_rc tarballs at this time > to promote further testing.] I do not agree with (3) because it doesn't support objective A. I think we can branch *any time* we want if testing is complete for the long running arches. We should try quickly identify defects, fix them, and then branch and cut the release. >>> 4) Release: from release branch, not master >> >> What benefit does this bring? > > The only real benefit is that we have master open for new code again > after 4 weeks of freeze, as before. > > If everyone is fine with waiting two more weeks, why not. Then we can > do the bugfix period on master and tag the release on master. > I'm not the best person to judge how bad the extra freeze time is. Lets try it out. Lets do 2 weeks of extra freeze time, but focus on getting all machine results and see if we can cut and release EARLY. :-) > That's all. > > >> Conceptually I think I understand what we want to adopt here. >> >> That the main development branch is always development, and that we cut and then >> make the required changes for release. >> >> >>> What do you think? >>> >>> Cheers -a >>> >> >> > > -- Cheers, Carlos.