From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id GI4tLCvF2mZYmQAA62LTzQ:P1 (envelope-from ) for ; Fri, 06 Sep 2024 09:02:35 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id GI4tLCvF2mZYmQAA62LTzQ (envelope-from ) for ; Fri, 06 Sep 2024 11:02:35 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=VPwd9fai; dmarc=pass (policy=none) header.from=gnu.org; 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=1725613355; 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:dkim-signature; bh=0ZfNcbIvLFjMLM7XLq6vG+fGcTrOukN/ZjaPNTL/HJM=; b=SvjHkuKA9le6UdtULrL6dI/y41BM188nprH4WFfVfBcbch4ycKt02SS4YbcB2T3CleCTW2 fnaa5KcM+5UHzbXuRtVWIB4n9iF3Qpaf/uThoT9+LJ0hA7B5ZsV4qJogBX0jx1PF8Fgehh uujt96qUmNPmoilm4wFZ+m5aeeLnRNGN6KFdT1QnXoKWokMHmAi06ng1wlOlKST47FDQpb 2uKCqZjppUrgRqnWLG+1beuxuGTDr3HDBYi51eoI83+DA0LZHUg8u0zK/GOUPIsJ1CzCqA zz+k+s2g1ydW76fhYmtK4d9mJAw8diCcng08bCmqETVH23SO/OwCfojFi7/lGQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1725613355; a=rsa-sha256; cv=none; b=Ldt0TqqqgwYaWML805Qwqz5Rths0+s48jEtlakhyyx867MUSfogFmQGnvaXHniaJmWIoQu 1PYWdEz+5IOeN6krz9Hpe3KYHOEqhosnX1CFwgij6YYBBQj0KUplDY60oJJKgJ3nGHxfPQ xe1UiM//orScSmieLdIAkhsDGAuqawMVZuboQ29b6rCO96kOMq4tzdvuqNpl8z7aW1mnMq t3EQOGPvBTd6jBYQPNcIuZBZlVUMwdzhZiGITM1E/u9ngFDgptCZBFDlX+VPZmz6Zfj7/e 8uXdUUp5f7HU4sUsU6tCZCBboL4BhTm3Fb/MJ9PaY3xPx5GN8YpYvf7QFK+7aA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=VPwd9fai; dmarc=pass (policy=none) header.from=gnu.org; 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" 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 9BF07612F1 for ; Fri, 6 Sep 2024 11:02:35 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1smUqx-0002O0-Oq; Fri, 06 Sep 2024 05:02:03 -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 1smUqm-0002HO-DC for guix-devel@gnu.org; Fri, 06 Sep 2024 05:01:55 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1smUqk-0001ZX-NB; Fri, 06 Sep 2024 05:01:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=0ZfNcbIvLFjMLM7XLq6vG+fGcTrOukN/ZjaPNTL/HJM=; b=VPwd9faig7Cx+zPdhuUV dL/EFZ5+wPxO2Z/M0iUJJymzWVuWoOx4bhTiw7k4pUS9U+uidWVA/HUcwSQ9MPlqlab39rAyKTrqf 5hOf1KI2md0yHRgO7NPGyLpn4I3bdCzSWqF2Vgq4uohgl/vt5Yg8Wsu3UAhT0MhZZv68PbNFos8jq BYOxJ8Pk5D6Mfxc9Hqfjx4jb7uCidwwMzo8POIr2XUGDRoQJDYTWY17jdsNCWvFek1Vl2ZEuPYcq0 ZiKJqlSO/MHy8BLweeXoSc48IY4qs5KLbhIJTb9udYeMmPT02F3oxcoua6o0I9Uk1fqg7Cvx4futk zDRaiRmdEWd3hA==; From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Steve George Cc: guix-devel Subject: Re: =?utf-8?Q?=E2=80=98core-updates=E2=80=99?= is gone; long live =?utf-8?Q?=E2=80=98core-packages-team=E2=80=99!?= In-Reply-To: (Steve George's message of "Sun, 1 Sep 2024 17:34:13 +0100") References: <87le0cj13e.fsf@inria.fr> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: Primidi 21 Fructidor an 232 de la =?utf-8?Q?R=C3=A9v?= =?utf-8?Q?olution=2C?= jour de =?utf-8?Q?l'=C3=89glantier?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Fri, 06 Sep 2024 11:01:46 +0200 Message-ID: <87h6at2m11.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 X-Migadu-Queue-Id: 9BF07612F1 X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -11.22 X-Spam-Score: -11.22 X-TUID: ZWeTs5g6zj3X Hey Steve, Steve George skribis: >> To reduce world rebuilds, perhaps we=E2=80=99ll sometimes create =E2=80= =9Cmerge trains=E2=80=9D, >> whereby we=E2=80=99ll merge, say, the branch upgrading CMake and that un= grafting >> ibus on top of =E2=80=98core-packages-team=E2=80=99, and then merge this= combination in >> =E2=80=98master=E2=80=99. The key being: these branches will have been = developed and >> tested independently of one another by dedicated teams, and the merge >> train will be a mere formality. > > Under the 'patches and branches' workflow, what should happen to packages= that are *not* part of any team, but do cause a rebuild of more than 300 d= ependent packages? > > Andy Tai gave an example of ffmpeg [0]. There aren't enough contributors = or committers for every package to be covered by a team, so this seems like= a permanent constraint even if more teams do grow over time. As Chris noted, there=E2=80=99s no requirement for a branch to be associated with a team; we won=E2=80=99t have teams for every possible package or pack= age set. In the case of ffmpeg, I would suggest creating a =E2=80=9Cfeature branch= =E2=80=9D changing ffmpeg and only that (or possibly packages directly related to ffmpeg). We=E2=80=99d get that branch built so those working on it and ens= ure it does not lead to any regression. Once it=E2=80=99s =E2=80=9Cknown good=E2=80=9D, I see two possibilities: =E2=80=A2 Merge into =E2=80=98master=E2=80=99, especially if it turns out= that binaries are already available on the build farms. =E2=80=A2 Attach to a =E2=80=9Cmerge train=E2=80=9D. For instance, assum= e there=E2=80=99s a branch changing =E2=80=98gsl=E2=80=99: this is totally unrelated to =E2=80=98f= fmpeg=E2=80=99 but it also triggers a lot of rebuilds. We could tack that second branch on top of the known-good =E2=80=98ffmpeg=E2=80=99 branch, and, once it=E2=80= =99s all good, merge that =E2=80=9Ctrain=E2=80=9D into =E2=80=98master=E2=80=99. (To be clear, the term =E2=80=9Cmerge train=E2=80=9D originates from GitLab= -CI and similar CI tool, which use it as a merge scheduling strategy: . GitLab-CI can create merge trains automatically I believe, but in our case we=E2=80= =99d do that manually, at least for now.) > Long-lived branches and ones that don't cleanly apply onto master cause l= ots of difficulties from what I've seen. Perhaps a lesson is that branches = should both be stateless *and* should not exist for more than 3 months. We = already have a rule that encourages atomic changes within any patch in orde= r to make things faster/easier to review. By extension, lets do the same wi= th branches - merge them more often. Agreed. And I agree with what Chris wrote: the current wording (create request to merge when the branch is created) should help reduce the risk of having long-lived branches. > I would propose a patch to the managing patches/branches sections of the = manual depending on what the consensus is here. I think this is a work-in-progress, so any improvement here is welcome IMO. Thanks, Ludo=E2=80=99.