From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id 0KT6DZh4EWTxvAAASxT56A (envelope-from ) for ; Wed, 15 Mar 2023 08:49:44 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id 2GAZDZh4EWRYvAAAG6o9tA (envelope-from ) for ; Wed, 15 Mar 2023 08:49:44 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id D8E6D2D0AF for ; Wed, 15 Mar 2023 08:49:43 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pcLsW-0005dT-Q8; Wed, 15 Mar 2023 03:48:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pcLsV-0005dH-No for guix-devel@gnu.org; Wed, 15 Mar 2023 03:48:55 -0400 Received: from hera.aquilenet.fr ([2a0c:e300::1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pcLsT-0004J7-Rj for guix-devel@gnu.org; Wed, 15 Mar 2023 03:48:55 -0400 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id 8E1EEB4B; Wed, 15 Mar 2023 08:48:49 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at hera.aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNFHKLSlruMm; Wed, 15 Mar 2023 08:48:49 +0100 (CET) Received: from jurong (unknown [IPv6:2001:861:c4:f2f0::c64]) by hera.aquilenet.fr (Postfix) with ESMTPSA id CA0A7AF; Wed, 15 Mar 2023 08:48:48 +0100 (CET) Date: Wed, 15 Mar 2023 08:48:47 +0100 From: Andreas Enge To: Maxim Cournoyer Cc: Felix Lechner , guix-devel@gnu.org Subject: Re: gnu: inetutils: Update to 2.4. Message-ID: References: <87lejzmisn.fsf@gmail.com> <87edpqlsza.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87edpqlsza.fsf@gmail.com> Received-SPF: pass client-ip=2a0c:e300::1; envelope-from=andreas@enge.fr; helo=hera.aquilenet.fr X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1678866584; a=rsa-sha256; cv=none; b=o1xrvVsUbAbsCjpocCbQ9f0bNbDbY48N7UNAszbxwaUhdYX8zCbsvcyVuPsj2AugbVSWMI 6+rB+/MVwl6eUHoxwPnXXskQXlKX/Q93FYayJJJLpYFot7pq6Ri5bMnU4IRT1maiPrvRZ6 ZCOphyslha0N9riIQmtqMcsADguFrl4XH/o0soRsyv7eQf7DCVWMDbN1TCzYpzFh0zB+jh 76qSN0xb8VIXwtpBd5Q68LndZBPt6Iprl4meyGuX7XYK5UFT6oDWrrkh4bzdn4wNoSv5pz 0HyWY4NCarQFwRucX4gE7fHOOP+Mz96o6pyrrYl/y2kL2pAKiF8/N5ZwhvIMNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1678866584; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=1Va6cNIduo3Ty1Jt+1Xcj5Bf4fdZSWviagHI/n6F9K0=; b=SKArg5Cn6x1aCzYjxUribrS/pvBlBnBAMnLHT1nWvNQUMefkYJ8AoDYhFuliPJa6Q3WfBc O0Ds7+8ebXBoTqR+VvTE42qCkngZXvukZvnibqsJ4n03jF3Tutp5YbYxWJFj5IZ9yDv9/w 410jubIy9mGm7UP9KyAfWV8qCFJ7/ZCW5p161lRSzriOyLkT6mmBH6yMiNfqaCCs+dCTB1 zpS9s1DQta2mSMNiCHEeeDBJr09DJy9dBPT/+zZRTz2vX7Tw1LOfUImk3Bouc5BtbdxIip ZK3qKESDT/2AuFfaYtzS3yhdbj1L9tXqJ360iMTmMGKyvnL5BpqPJLOQG9NlSg== X-Migadu-Spam-Score: -2.53 X-Spam-Score: -2.53 X-Migadu-Queue-Id: D8E6D2D0AF X-Migadu-Scanner: scn1.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=none X-TUID: LguTo6yjfYJ3 Am Tue, Mar 14, 2023 at 09:10:33PM -0400 schrieb Maxim Cournoyer: > Could you share the reference of that? I'm not against it, but our > currently documented process still mention the good old staging and > core-updates branches. It has not been documented yet, we should do it. Here is the relevant excerpt from my notes, sent to guix-devel on February 9 under the title "Discussion notes on releases and branches": - Create branches with a few patches or patchsets; in any case with a "semantic" description of the changes. The branches could be shortlived. Feature branches are one incarnation of the concept. - The numerical criteria for staging and core-updates is outdated: Even non-core packages may create an enormous number of rebuilds. - Negative point: There is a risk of churn, by not regrouping world- rebuilding changes - but two non related world rebuilding changes might be difficult to review. ... - There is discussion whether we need a core-updates branch. Core updates concern the toolchain, build phase changes, everything that has big ramifications all over the system. It would be important to not have several "parallel" branches with related (for instance, but not exclusively, core-update) changes, which in fact should come one after the other. Either they could be collected in one branch, or would require coordination of branch creation (inside a team, say). - "Merge trains" of gitlab are mentioned, as a way of merging several branches at the same time. There was a consensus on advancing in this direction, but details need to be fleshed out. The core argument I see against core-updates (and staging) is that they regroup a mixed bag of unrelated changes, that noone is able to audit after a while. By matching a focused set of changes with a dedicated team of people competent in the area, we hope to advance faster and in a more concentrated fashion. This comes in a context where our compile power in the berlin build farm is much larger than in the past, and where on the other hand a growing number of packages lead to non-core packages causing a number of rebuilds that used to go to core-updates (like we just see with inetutils). > Until everybody has a good grasp of the new process, I think sticking to > the documented one may be best for now, as it makes it clear that this > cause a mass rebuild and shouldn't land to master. Definitely in all procedures, old or new, mass rebuilds should not be done in master! Andreas