From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id OI8hA/vk5GPcfAAAbAwnHQ (envelope-from ) for ; Thu, 09 Feb 2023 13:20:11 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id 6BQGAvvk5GNjHAEAG6o9tA (envelope-from ) for ; Thu, 09 Feb 2023 13:20:11 +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 8F2423CE3C for ; Thu, 9 Feb 2023 13:20:10 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pQ5tr-0004dM-Hl; Thu, 09 Feb 2023 07:19:39 -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 1pQ5tq-0004cz-BC for guix-devel@gnu.org; Thu, 09 Feb 2023 07:19:38 -0500 Received: from hera.aquilenet.fr ([185.233.100.1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pQ5to-0003a3-8f for guix-devel@gnu.org; Thu, 09 Feb 2023 07:19:38 -0500 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id DF9BA1C9D; Thu, 9 Feb 2023 13:19:30 +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 74NVR_LTlIOA; Thu, 9 Feb 2023 13:19:30 +0100 (CET) Received: from jurong (unknown [IPv6:2001:861:c4:f2f0::c64]) by hera.aquilenet.fr (Postfix) with ESMTPSA id D6C19296; Thu, 9 Feb 2023 13:19:29 +0100 (CET) Date: Thu, 9 Feb 2023 13:19:28 +0100 From: Andreas Enge To: guix-devel@gnu.org Subject: Discussion notes on releases and branches Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1n6UhtUGkhLc/RQO" Content-Disposition: inline Received-SPF: pass client-ip=185.233.100.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-Seal: i=1; s=key1; d=yhetil.org; t=1675945210; a=rsa-sha256; cv=none; b=meG9gv8aFHLFAOGM37TrWHWaLPKnb/NzcxBKRkSOEb7R8amHSOMZJYcX76ktTZfng2k2II bT9DTlrPOuR/X3qF8oDkxHGyHbsLY+42OTQacKGF+hWuttTDOuJ8RpPLBWw2H4a9nNB5Tv PQO66QFcInixedx3pGUL8sK8caSNX4We+mTQeqWLZN+l1gMpBKOE5nWmifolkb1ya7W83H QmyLVBsphQhMP9GSiQcGuf5DWch5wXHLf6X7X6Cvyt1FXBkyThbfyuZrK1TQImJaEDqm38 NX5jF1ppa5C1nPHIo1L/132YrKT3x9I0DBtECrhjHQAXlAJux8IuEuPvKL+6AA== 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=1675945210; 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:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=zWOkXa8ln6taUhlNgcInsJhlXEiezkxNJH2++/Xq4vk=; b=kmUyMCXS2aigunKWUk/uF7b4OcioPoguaQpxuzRrynuCc6qyTHzF+xKk1Sh0nG2J63xqYo eoIzjT0Yp3+JnvKvk1hFTLOJo0ZCt/TOCwWCmxC5mRGu5WVyr/Uy93vwlkH7fJrqh/ns8f wU8ZaV7yEQzCmFlknHLENix5uvnj7oWrP4WuBpcb5lKplZb3xTEu367VaqiBxauO7p6w/w 5HnEelyivmAbf7rbFe3makkEUUmfiAoTGoNxJJXp+aDAEFZbiOWCEnnrgF9KGmniHGj9J7 YuyDV84tBQAZlfQMNnWjQEIxdXK8ghwuslJ8aVmeVfpEACbT+NHSs5lZM+4pOQ== 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-Migadu-Spam-Score: -0.90 X-Spam-Score: -0.90 X-Migadu-Queue-Id: 8F2423CE3C X-Migadu-Scanner: scn1.migadu.com X-TUID: OWF8Xx8liC5g --1n6UhtUGkhLc/RQO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Attached are the notes of our discussion at the Guix Days concerning releases, branches, teams and related matters. Andreas --1n6UhtUGkhLc/RQO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="Release.txt" Releases, branches, teams Problem: It took us 1.5 years for the last release, and the coreupdates branch has been open for at least as much. RELEASES Why do we make releases? - How else would people install Guix? - Quality assurance: Fix the installer before release. - Regular points for translation. - Communication and publicity. - Releases are separate from branches; the release team should pick a commit and spin off a release branch from there. - It is possible to have long term support release, mixed with more frequent intermediate releases; example from another project: "big" release every year, "smaller" releases every 4 months. - Stable branches are a frequent user request! - A release schedule for a release every 4 to 6 months sounds reasonable. - Mathieu, Simon, Julien and Andreas volunteer to be members of a release team. The idea would be to change the team for each release, with an overlap of about half the people: everyone would have "two terms". Such a team could commit on a release date and coordinate contributors, keep track of the status, ping people fixing bugs etc. Work should start immediately after a release to spot problematic areas (poorly supported architectures...) and big goals for the next release. It could also coordinate with other teams on planned big changes. Communication is key! For instance send a status update once per week. At the same time, the team should lower their operational involvement to avoid burn-out. BRANCHES Suggestion: - Spin off a stable branch from master with security fixes, maybe important backports; after 6 months, branch a new stable branch from master; this is almost like a release, but continued into some future. Counter-suggestion: - 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. Before creating new branches, we need to clarify how the old branches are handled! - Smaller branches could be taken care of by dedicated persons responsible for pushing them forward. For instance by teams. - Some people already do this for a feature branch on their local machine for medium-sized updates (ocaml), or even on ci (haskell, kernel updates). - Branch creators should fix a goal and tentative timeline. - We need a mapping between branches and maintainers responsible for the merge. This could be a team leader, if such a role is created. A wiki could be used to keep track of the branches. - 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. - Grafts can also be handled in feature branches: The graft is applied to master; the graft is applied to a different branch, directly followed by an ungrafting commit and an update of the corresponding package; once the branch is built it is merged back to master. - Minor drawback: If qa has treated a world-rebuilding patch, the substitutes will be available on bordeaux, but not on berlin; people who have installed a long time ago and not authorised bordeaux might be affected. If there are complaints, they can be handled on the mailing list. - Moving fast poses problems for non-x86 architectures, but the build farm situation has improved for aarch64 and armhf sufficiently to keep up with master. Handling feature branches remains an unsolved problem. - Currently there is a cap on qa, only patches with at most 300 dependents are treated. This cap could be increased. Or it could be weighed with the build times of the packages. TEAMS - Issues could be tagged more often with responsible teams, or with severity information (blocking bug or not). - Each module should be covered by a team; otherwise it would be difficult to get important updates through a feature branches. ARCHITECTURES - We distinguish in the manual between available architectures that are "supported" or "unsupported". It would make sense to have a category in-between, with architectures that are supported in principle, but may be low on substitute availability. - We could use the "supported-systems" fields in packages more liberally. --1n6UhtUGkhLc/RQO--