From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id nSBnJJpW6WMjggAAbAwnHQ (envelope-from ) for ; Sun, 12 Feb 2023 22:14:02 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id 0HinI5pW6WOxyAAAauVa8A (envelope-from ) for ; Sun, 12 Feb 2023 22:14:02 +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 1421311DD2 for ; Sun, 12 Feb 2023 22:14:01 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pRJfM-0004mX-1L; Sun, 12 Feb 2023 16:13:44 -0500 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 1pRJfK-0004mO-7L for guix-devel@gnu.org; Sun, 12 Feb 2023 16:13:42 -0500 Received: from jpoiret.xyz ([206.189.101.64]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pRJfI-0006TP-At for guix-devel@gnu.org; Sun, 12 Feb 2023 16:13:41 -0500 Received: from authenticated-user (jpoiret.xyz [206.189.101.64]) by jpoiret.xyz (Postfix) with ESMTPA id 12FBB185300; Sun, 12 Feb 2023 21:13:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jpoiret.xyz; s=dkim; t=1676236418; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RvxQaPdeGlfZeQrw8YnpYH7TEnam5gFcTAzMONvoVp8=; b=AjEJU1wEriXusNa9Z5cqjWDHWLqPhEyPFu7+m7KL+WJrNFNO5OVc41zqUopnyJCRo58OTz 7bEH8nTvWqOdLwXE57cCok4TfYzYsuBOmbH1oZrAHF3Cfy69XMqxF6US0zJIGrFZTKTaDW jzhBbBBgUSyfnffq91BSwuX0Mo+130rGs7neUKcg35XCTHFPfFYSMmH7BVsCW5igbM0eQ5 hEBeBCUNkDWWRtETo1RnyNNlwLmQ69/Euq2zIzSgkkItAkvgvAvTTBFwFTOx5Q8qf1Q1y+ Otro2ov6UYf6Yp67cTLwyMWh+MdY6byhZThbrVo1SE+jSqJ3mO4wZ+RLllOaUw== From: Josselin Poiret To: Andreas Enge , guix-devel@gnu.org Subject: Moving forward with teams and feature branches (was: Discussion notes on releases and branches) In-Reply-To: References: Date: Sun, 12 Feb 2023 22:13:35 +0100 Message-ID: <87bklyd1ts.fsf@jpoiret.xyz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Spamd-Bar: / Received-SPF: pass client-ip=206.189.101.64; envelope-from=dev@jpoiret.xyz; helo=jpoiret.xyz X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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-Flow: FLOW_IN X-Migadu-Country: US ARC-Seal: i=1; s=key1; d=yhetil.org; t=1676236442; a=rsa-sha256; cv=none; b=OHP7ndgPbQHf33OsMfUCUbncTKrmKpW+sXzVMjAK903gH+BcUYQ4oUuU2lxaBzPVBEbFFB Lc57dp50OKfrtvCwR295V2YkH92vJp9YlIZJgwI/G/P/p54zcTAG64xGIpnBDMuFShyy0b +DAgSQ/pG3/vxaPL8/lfTb9hR6Dle1QLG7TmfqgkYodqnkhwSpq7nJt/BlyzsrkcGrBXnN E5OTeJUtA+jIaFiGNiK+bQQSq0FIBFxpH4BPJpnevnzaFAX6wIn89utDl6l+k7ILo8VUe2 Xd3PUtfnlTJJqTRjaTfRVUX0c0rIjTRJDx9MGb/57Qc/gmqauSeW33WuZ69jTQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=jpoiret.xyz header.s=dkim header.b=AjEJU1wE; dmarc=pass (policy=reject) header.from=jpoiret.xyz; 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=1676236442; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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:dkim-signature; bh=RvxQaPdeGlfZeQrw8YnpYH7TEnam5gFcTAzMONvoVp8=; b=Cealzr/Q3ngu6KsDJrtVB8aByr0vqDiusmjBUZGrib67o24IrYDX5i0xn8ODkK7KRKHrH6 uIwiooGN+3dQD2zO3TuDonNscSJQAQG3ql83yI8YqBJYTLYMg/hG8JMhfj9rI1kxF1BvjU 3aaEkt7dDUajVXNmXyGEIcF8ovdmwEVpzpv7gSa5O8nnkNKMQn52S6xc+saAGPQ7bkA8ct 5VzYNKQjvD5NOPNI7aIRXhDSB/lRXn57XHHU34pFkKkQ4MTZ0zasSuaWDneI9e+S3UPwZ3 cDgRxDuZ+9F/FWlqPVhTxy05+2wgk9Zp2L1r9bPyX9oRv5qet2+ZpKKT+tbbJQ== X-Migadu-Queue-Id: 1421311DD2 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=jpoiret.xyz header.s=dkim header.b=AjEJU1wE; dmarc=pass (policy=reject) header.from=jpoiret.xyz; 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-Migadu-Scanner: scn0.migadu.com X-Migadu-Spam-Score: -5.72 X-Spam-Score: -5.72 X-TUID: 1cNp0qdGE2z+ --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Andreas and thanks for taking the notes during the discussion! I think what came out of that discussion was very interesting and that it would greatly help the scaling problems Guix is facing as well as maintainer/contributor burnout, but that also means that we need to create some actionnable plan out of it. The window before the eventual core-updates merge would be the best time for it, IMO! For that plan to materialize, the best would be to agree on 1) what we want the new workflow to be, and 2) how to get there. To start the discussion, here's what I got out of the discussion (and is probably opinionated): The envisioned goal state would be to stop relying on staging/core-updates to manage non-trivial changes to Guix, but rather have specific branches that could be merged way faster, because they are focused on specific features that people can feel responsible for, instead of a hodgepodge of unrelated patches that no one wants to debug. These feature branches would be managed by teams, with one person from the team being responsible for the feature and it getting merged into master. Those features could be ephemeral or long-running and each team would be free to organize around them as they see fit, since e.g. a Stack upgrade is very different from a Mesa upgrade, or a gnu-build-system change. With the improved CI/QA we have now, we shouldn't have to worry too much since substitutes will be available right away (we should weigh what's acceptable for people using --no-substitutes vs. keeping software more up-to-date though, but my opinion is that in favor of the latter). Teams should thus better document how they work and what they do, either in the Guix documentation or a specific wiki/manual that would be maintained by team members themselves. Having all information in one place would help outsiders find their way around the inner workings of the project. Maintaining roadmaps for each team, with who's working on them and where that work can be found would also lure unsuspecting bystanders into working on Guix features, as well as structure the future of Guix; it shouldn't be too codified though, since we don't want to further burden precious team members. One nice thing about documenting all of this using a manual is that the changes go through the guix-patches ML, so that they can be discussed and recorded for the public to see. Note that this change would also mean that contributors are no longer responsible for gauging whether a patch belongs on master/staging/c-u, but rather the reviewer/committer. Also, as a nice side-effect of the change, I can see people getting interested in joining teams because they structure longer-term effort that's put into Guix, not just because they've been maintaining python-foo-for-bar for 5 years against their will. Regarding releases: a release team would have to keep in touch with what the other teams are doing, make some sort of periodic status report, and set deadlines such as feature freezes before preparing a new release. For a potential roadmap (doesn't have to be sequential): 1. Document this workflow in the manual, in a dedicated node, with a rationale as well. One thing worth mentioning would be how to handle grafting/ungrafting now. Also remove the staging/core-updates criterion. 2. Teams start organizing around the features they are currently working on, and document them accordingly. They can also draft how they work, what they do and their roadmap if they wish. 3. CI/QA gets examined and updated to support the new workflow. We test it out with a sample feature. 4. staging merge happens, and the branch gets deleted. 5. core-updates merge happens, and the branch gets deleted or repurposed (up to the core team). I bet I forgot a bunch of things, but at least we get the ball rolling! WDYT? NB: Just noticed there is no tooling/infrastructure team, this would probably be a good idea, to publicize the incredible work that is being put into all of it (mumi/cuirass/qa front page/the data service), as well as bring in some new souls and document how they all fit together. Best, =2D-=20 Josselin Poiret --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHEBAEBCAAuFiEEOSSM2EHGPMM23K8vUF5AuRYXGooFAmPpVn8QHGRldkBqcG9p cmV0Lnh5egAKCRBQXkC5FhcaiiZtDACJE0A+1QqIffEm6fXf6bf7U1Gd7ijk8/bU YASUXikRLVtOk3ejG85lLvGKXmCYy3tsrhF0O/v/l2j+Bo/bowKHInMRbBs3SLFd Aqq9DmKa/+j8tsVKpHqbeDxj7nbEpAFfBhqxHtFp8jxJRhwvnDgbXh61hrFuM6/S TuNRkT6VL87uZ44TkoTIf+VnrilcunZ1SlmLKVyxmVKjH3Sw24K4RLeR0naqXaS/ HtCI83ROhWSSv8MXDZCJ09gB48hMhtyHGfgcjvsnXHdZwWt4dktl3/apQt1z7FCC U95a3nGTmdWz4CFsspct2gI2TWxiN8j5pLO0IHOWs9gPcjboogXWITkGd3h2xeBY UXtA2AmCAK02qUUJlv5wsFIsgEL3X4SwanJLoZGhcqVU8DI50CYRU4nSZ+MOmE7s +o2IWHASBT9XwNqMKtxTO6kEuBe6X0si9m2jxsGly4gOFD5tv16Iajm7raRVJdm9 c83FyRSyXrpC7zj/pKOCbhSzohAvam4= =rqKz -----END PGP SIGNATURE----- --=-=-=--