From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id 2LReFGnx2maM2wAA62LTzQ:P1 (envelope-from ) for ; Fri, 06 Sep 2024 12:11:21 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id 2LReFGnx2maM2wAA62LTzQ (envelope-from ) for ; Fri, 06 Sep 2024 14:11:21 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=marekpasnikowski.pl header.s=dkim header.b=jtjTTqHG; 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"; dmarc=pass (policy=reject) header.from=marekpasnikowski.pl ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1725624681; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=GHGlWrL3KRRZodgjORDH2pjzyCqmDLt8Fns3yCcnQ00=; b=OYAKUpTZpxSHFwLJDG4rpTijDPGE5D0RzDRUdnbt86Y6XRwg1MGmCy18kQKH03Nf8nUVxH FFH5NTZ6ikGZCD3proGtCNNIp3TCxwr3g2lGpnh6YDP7P1sY/PfRg9ujwq5V5KiPh+VFpi cnoWNkvGUF5ybi9cUDyw758tG+DDlxttjILJd0Vd+ND8Q7k6ReO8j7BqU7Zm3l3I403KhO eKy/nwWj2y+Ahtnnt6I1YEDhQMSAuKME6EHYJhpDnH5jO8BpH+s+UA+GGpE//wX3uDT2HL 8uKxohyHs21IdoItVpMeowr7rBhDNGlIoz/DGXnQDKWvo6ICBtIqEUoQJw/YAw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=marekpasnikowski.pl header.s=dkim header.b=jtjTTqHG; 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"; dmarc=pass (policy=reject) header.from=marekpasnikowski.pl ARC-Seal: i=1; s=key1; d=yhetil.org; t=1725624681; a=rsa-sha256; cv=none; b=T2niyzK94/Q1yAP1Ji39h7L8D3GIXBUUOajVNxwECLcfgYF8SGRkxuf/3lQBRfjhldVM6x qexXtPJASjl/sdktCjh98XPXn7/xEPF/CDef/lkoedDYorFfFOoNkDffP5MnJFUoiOk3eY /ANT5FN2XpNh8JQXfpojD4X8Dal8e2NOC6HZcWtQVDKZwU/M1uY9qA0xI3F0HRPN1el+wN JyN+e16vKfXIahBgYVcofhEaROKReI1Fw03PjGNYZ7uMkNSBvXq8npNhNSXk0KZ7qZubXn phH4BrvJtRbvvHGyIRnHSNhmFFPOi8xMsiG9qt5N1Hle52Cl8e3ojq0CPAApYQ== 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 28F34F499 for ; Fri, 6 Sep 2024 14:11:21 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1smXFy-0004dK-12; Fri, 06 Sep 2024 07:36:02 -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 1smXFq-0004Ed-AC for guix-devel@gnu.org; Fri, 06 Sep 2024 07:35:55 -0400 Received: from [81.190.248.246] (helo=marekpasnikowski.pl) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1smXFo-0002wo-97; Fri, 06 Sep 2024 07:35:54 -0400 Received: from localhost (localhost.local [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id 95686f26; Fri, 6 Sep 2024 11:35:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=marekpasnikowski.pl; h= from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-type; s=dkim; bh=9Q26WQEbj4a8vwJ37wARKFJ9d Uc9Ldg/pCHYAxfP2PA=; b=jtjTTqHGtUqscRdPkzmouZqhj823GYtdx9vGt2cmk 9mWScCx9nPExf5143E2OGupm1MUYh90zQwekDyAe6QqPXrWdrtKZSogNjCwKH77E 6v9G6/awU9TLVQ2uqzcQ+ELEaO1coGK9t5J83B9V+viEJRzhsGvfhJKNd9YfzIFL gcchqb9gYO5RsgK9SxSBWNmV+UH3CO00f5RBkXf6/12rwZ4+ooUmmzJpjlCWUzf6 9KRvcK98pSTZX8JXZEI/EvJfkza1te3RuI5qKSILJ1/g5Q48VpVOWiblGMyuFFFm J4ndRHhY9/L48YPB2cM8dHgSLrEsGk5LkI6hBq+Gj9jJA== Received: by localhost (OpenSMTPD) with ESMTPSA id 8c34b693 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 6 Sep 2024 11:35:43 +0000 (UTC) From: =?utf-8?Q?Marek_Pa=C5=9Bnikowski?= To: Andreas Enge Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , Simon Tournier , 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: (Andreas Enge's message of "Fri, 6 Sep 2024 12:09:05 +0200") References: <87le0cj13e.fsf@inria.fr> <87v7zby3r6.fsf@gmail.com> <87zfol170t.fsf@gnu.org> Date: Fri, 06 Sep 2024 13:35:07 +0200 Message-ID: <87h6atgglw.fsf@marekpasnikowski.pl> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Host-Lookup-Failed: Reverse DNS lookup failed for 81.190.248.246 (failed) Received-SPF: pass client-ip=81.190.248.246; envelope-from=marek@marekpasnikowski.pl; helo=marekpasnikowski.pl X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 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, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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 X-Spam-Score: -10.61 X-Migadu-Queue-Id: 28F34F499 X-Migadu-Scanner: mx10.migadu.com X-Migadu-Spam-Score: -10.61 X-TUID: tn2rqIfkDfmC --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Andreas Enge writes: > Hello, > > Am Fri, Sep 06, 2024 at 11:11:14AM +0200 schrieb Ludovic Court=C3=A8s: >> The way I see it, one of the branches would be tested independently. >> The second one would also be tested independently, but on a limited >> scope=E2=80=94e.g., x86_64-only, because (1) we usually have more build = power >> for that architecture, and (2) perhaps we know the problems with those >> branches are unlikely to be architecture-specific. >> Then we=E2=80=99d rebase that second branch on top of the first one, and= build >> the combination for all architectures. > > Once the first branch is good, why not simply merge it to master and then > rebase the second branch on master and test it, instead of postponing the > merge? After all, building is costly, not merging. * What if an unrelated branch gets merged before the two considered in the example? I suggest to generalize the process like this: 1. branch based on master, passes QA -> merge 2. branch based on master, fails QA -> fix QA, go to 1 3. branch not based on master, passes QA -> rebase, go to 1 4. branch not based on master, fails QA -> fix QA, go to 3 * What if a branch is worked on for a long time and the rebase itself becomes non-trivial? The rebase process could be split into multiple steps, each corresponding to successive merge commits in the master. The process could be further made easier by introducing a policy where each merge commit to master must be tagged with a unique identifier. By a =E2=80=9Cmerge commit=E2=80=9D I mean any commit that brings a branch bac= k to master, including fast-forwards. Thanks to the unique tags, not only could other branches rebase without having to resort to commit hashes, but also users could confidently point at specific points in the history to base their systems on. For example, if a new version of an application removes an important functionality, they could pin the guix channel to the merge tag before and take their time to implement a solution. > Notice that with QA, the concept is that the packages will be available > on the build farm once the branch has been built, so postponing a merge > has no advantage. I think that merging reviewed code often is a good practice, because it could make rebasing in other branches easier to solve in case of incompatibilities by decreasing the scope of change at any particular step. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJOBAEBCAA4FiEEWQ5QD+OdJrPmC3Q7bYGxIHcRiZ8FAmba6QEaHG1hcmVrQG1h cmVrcGFzbmlrb3dza2kucGwACgkQbYGxIHcRiZ9GaBAA8BTfi4EVLN24rDvzY1Cq 36Pce3AyO71goEN3HbFyy49+fVaMzm67jruAS217aDmXnIfM+W4Rai5NGCxfKeLh Sd9KA0aOgmMT1lm6BHhhpk3Du63PENM1MSLP8y4tfpV9R+mLVTsihtcO80GElmxr KTA/OQnCtIoVDHGrDYkqdVgNLGioCc0A/0yPHZ2XVkTvykDSb4OqDBybGUe3TGg2 5RidDBFQLU4FF63MR9yk6DVXgdr9d/aCl0bA5/kQbsTfI0iD/HUe6R+J0Sx0Xz2/ JOqhFursRAO4yU7kh2aQBTDX9THTC2ogbrm28K/9yTdU/qzvvX6JvC5DTcRFSUWk dCrHKm+5LOp6KPCOc38jTqQIq+95PVDvHS0LwzOmFyTKfzhisubtNfw0dUPGgbmA QWLGNCqAX1qfsmy0WR+MywPXWcEadoEs2QdRlSusuFvUKwnJPAEG2zryf6nlX3Nf YFSNyoLOYXm9tRuTHPPOnB+C5tQD4dKBLMdwkBd4P81PIsx7YU3UrZUW545G6YcO uNEUvV++zpmCTJbSC7SsM8uwE3HbNC9YOhxcvyC+orHtZFaqJMXsu4nsxn4hl1mU 5sr1cRmU/Jznmx2Gnes9CkutEw1uwAWWwLxnHQvyUxn7Cv8cdqquh4STUxgSaJV3 glgCFIkaRfExQKOjMWxr1Qk= =ggD3 -----END PGP SIGNATURE----- --=-=-=--