From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id CLnvOqokWWSnfgAASxT56A (envelope-from ) for ; Mon, 08 May 2023 18:34:51 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id kLXeOqokWWSTVgEA9RJhRA (envelope-from ) for ; Mon, 08 May 2023 18:34:50 +0200 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 CDCBB3A69D for ; Mon, 8 May 2023 18:34:50 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pw3oN-0003kb-Nl; Mon, 08 May 2023 12:34:07 -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 1pw3oM-0003jh-D2 for guix-devel@gnu.org; Mon, 08 May 2023 12:34:06 -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 1pw3oG-0005fY-7Y for guix-devel@gnu.org; Mon, 08 May 2023 12:34:02 -0400 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id 9C1A9261; Mon, 8 May 2023 18:33:55 +0200 (CEST) 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 uMT3XeWabUws; Mon, 8 May 2023 18:33:55 +0200 (CEST) Received: from jurong (unknown [IPv6:2001:861:c4:f2f0::c64]) by hera.aquilenet.fr (Postfix) with ESMTPSA id CDE1E9D; Mon, 8 May 2023 18:33:54 +0200 (CEST) Date: Mon, 8 May 2023 18:33:53 +0200 From: Andreas Enge To: Maxim Cournoyer Cc: Christopher Baines , guix-devel@gnu.org Subject: Feature branches (was: 04/09: gnu: mesa: Update to 23.0.3) Message-ID: References: <168347913021.32190.10808857919894440138@vcs2.savannah.gnu.org> <20230507170531.26A00C22F14@vcs2.savannah.gnu.org> <87r0rrzjbr.fsf@cbaines.net> <87jzxjvxeg.fsf@gmail.com> <87ild3yltb.fsf@cbaines.net> <87v8h2vpdq.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87v8h2vpdq.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, T_SCC_BODY_TEXT_LINE=-0.01 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-Seal: i=1; s=key1; d=yhetil.org; t=1683563690; a=rsa-sha256; cv=none; b=fIvGxOjWsSLGpm6DIxrmh8caicTZ8xzCqkgAMphXbc4+OHpQ9UJL7jAxJgCth+o9JI5GvF XUExwP+lj+1+0HaUKReWPPUUWbWxDkboDbm8dpKQPMFQ7Nz/esUsPdrohAUPZQoaJuK5kh dhR5tFi3PYOBM1Gk9B+0TRGV+IO7g86ofxsFE77ppDhLB1c23ldBs3jl4HuAyWfHpRquOm FVk5FWvR0KaSlnwkzhHfhPWDOY2TK+pyQNGLkPcZJ4859wYFh+YrNXikkEU2EOS89ozaGz wwtpqYpPoPVG1IaJUybU5gBizsk0GytGodYI0/PX7bNKO02bJgn/MfAEVNXFKA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1683563690; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=mimGCqmPWD6WCXggZdhIuZyO5kP89ZL3FZi5Am9Ml1Y=; b=C1QST4bZYV9xnEhgB6iAeticW7YYP1mi/y5Gpc56eQbQY+FNDpFM81QsIBCPm+90VCZSHy SBMeVK+vv0F6OOG3sfWCMa8+SredHNdJZZgaQwOEyRzu53FF7Dy3upNoDxV0zfW0t5z0JR mTLlIRu9ux5FCVyQWf8LvMVO/I0qQpp0P+7yIKxsm7buO3NSuIxXHuCHXtyGaX13ox4NRZ AAFtM5vNxUjcBlJnKANLl5O0AoAWYClLLMDlM8VwwoEaoAH0WfmNqk14HPPm6dXkjSCn8k ieIE4A5npy41RdkJI4cwywp/kw7u8q4G5Zy8q6wK2yq9A+9NMKp05etKgFLiKw== X-Migadu-Spam-Score: -1.79 X-Spam-Score: -1.79 X-Migadu-Queue-Id: CDCBB3A69D X-Migadu-Scanner: scn0.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=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" X-TUID: rUHBpb1njNMk Hello, indeed someone™ should update the documentation to describe the new process. Probably we should agree on one before doing that as well... In principle all big updates should go through a feature branch now. However, this does not solve the problem of limited build power in our two build farms. Having feature branches that regroup several related changes should help in not rebuilding too often. In principle it could also be okay to regroup unrelated changes (mesa and gcc, for instance), as long as responsibilities are clear. It should be known who is going to act on what when breakages occur in the branch. And I think there should be some kind of "branch manager" and a time frame for the merge so that the branches are short lived. The goal is to avoid the core-updates experience of random commits being dropped in the same place, while hoping that someone at some later point will sort it all out. So how about this suggestion: A feature branch is created upon request by a team, with a branch manager designated by the team. It is accompanied by a short description of what the branch is supposed to achieve, and in which timeframe. The branch manager has the responsibility to communicate regularly with guix-devel on the state of the branch and on what remains to be done, and requests to merge the branch to master once it is ready, and to subsequently delete the branch. This does not yet explain how the branches interact with continuous integration. The branch manager may or may not have commit rights and may or may not be able to create specifications for cuirass, so the full process should take this into account. As written in a different thread, right now I would also suggest to first build the branch only on x86 and powerpc to not overload our few arm machines, but this is a technical detail. Andreas