From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 4M5iB/TpJmDKYAAA0tVLHw (envelope-from ) for ; Fri, 12 Feb 2021 20:49:56 +0000 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id EH4eA/TpJmCpAQAAB5/wlQ (envelope-from ) for ; Fri, 12 Feb 2021 20:49:56 +0000 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 A8C8311E88 for ; Fri, 12 Feb 2021 21:49:55 +0100 (CET) Received: from localhost ([::1]:41224 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lAfNy-0006VM-NF for larch@yhetil.org; Fri, 12 Feb 2021 15:49:54 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:36756) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lAfNe-0006VE-NQ for guix-devel@gnu.org; Fri, 12 Feb 2021 15:49:34 -0500 Received: from hera.aquilenet.fr ([185.233.100.1]:55270) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lAfNd-0001DZ-0v for guix-devel@gnu.org; Fri, 12 Feb 2021 15:49:34 -0500 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id AB0BC478; Fri, 12 Feb 2021 21:49:29 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at 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 QOjosYjprvv0; Fri, 12 Feb 2021 21:49:28 +0100 (CET) Received: from jurong (unknown [IPv6:2001:910:103f::ae5]) by hera.aquilenet.fr (Postfix) with ESMTPSA id 9C90A229; Fri, 12 Feb 2021 21:49:28 +0100 (CET) Date: Fri, 12 Feb 2021 21:49:27 +0100 From: Andreas Enge To: Leo Famulari Subject: Re: Changes to the branching workflow Message-ID: References: <87im6xd17e.fsf@nckx> <877dndcc6t.fsf@nckx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spamd-Bar: / X-Rspamd-Server: hera X-Rspamd-Queue-Id: AB0BC478 X-Spamd-Result: default: False [-0.50 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_RECIPIENTS(2.00)[leo@famulari.name ..,andreas.enge@aquilenet.fr ...]; RCVD_COUNT_TWO(0.00)[2]; BAYES_HAM(-3.00)[99.99%] Received-SPF: neutral client-ip=185.233.100.1; envelope-from=andreas@enge.fr; helo=hera.aquilenet.fr X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -1.86 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: A8C8311E88 X-Spam-Score: -1.86 X-Migadu-Scanner: scn0.migadu.com X-TUID: /zJ6YC/GvvNW Am Fri, Feb 12, 2021 at 03:17:34PM -0500 schrieb Leo Famulari: > What do you think? Should we stick with the plan I wrote in the manual? > Or change it? >From what I understood of the discussion, I would also go with Tobias's and Efraim's suggestion: There is a core-updates branch that is constantly open and where people can push; this does not seem to leave a possibility of mistake, almost by definition. Then we can branch off core-updates-frozen, which is frozen :), except for cherry-picked bug fixing commits and merges from master. Once it is finished, it is merged into master and deleted. The one thing where maybe problems can occur is that now there is the core-updates branch that has wildly advanced, and that needs to somehow be tamed to go with the new master branch. But the situation would be the same if it were called core-updates-next, I suppose. Technically speaking, this is the same as your suggestion, Leo, but it avoids the constant dance between core-updates, that disappears and reappears under the name core-updates-next, that disappears and reappears under the name core-updates, and so on. Andreas