From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id SDz/Eryt+2SVAwAAG6o9tA:P1 (envelope-from ) for ; Sat, 09 Sep 2023 01:26:52 +0200 Received: from aspmx1.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id SDz/Eryt+2SVAwAAG6o9tA (envelope-from ) for ; Sat, 09 Sep 2023 01:26:52 +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 DE6C234B28 for ; Sat, 9 Sep 2023 01:26:51 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=hgTvjL9+; 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=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1694215612; 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=MpCAeFSEKXT8ki5QiK+Ezu1ica80T+1ZfHrcUfcjSjY=; b=f6dqVykPhtCaK790TnZte7nKxG2DiNv6qvpFRH2jcKaAvBOzVsPsbzGL/spcbzZUa6Z3Qh rd2d5D4xCGFRETYVDNL6k8JnmX9jzb+jhvDtU+C8nmsNlk40PJ8GUMUGQhIgTIqrgHR11B fZ2JBHdIjzliFFHhBe1vgqi9LaqXbi1t0PavdmlFVGhepeFPASw2VFediBTK89iEI1FUAG xFFHDT70X3bT4g2X5UVuAn7u77CT4IwGzg2NZcTtyaCPuqb2A5xp4r87u+0RdFfgQluj6x FJT6PHsWleXUyGOS89BGt7tIkzDhEkngf6T6nNEdeSNcnc9DRy6PrJ+rq/CUcg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1694215612; a=rsa-sha256; cv=none; b=ckVOjTqulrgKUZ/7l540YFizEWRR+oUqMezZSfC7BzuLr23bnHNh7WL9W2DPRfmjTjLv0y YJduKZykqRDK+rpV/tT+Lv5rm7jSfz1Wh0OzaKIyfWWYNogi3GdC3NDPdZvYt/lxCD0Bo6 kjJmbGOp74lPsBQGiGFe766AYVenc7xRMbJpLD5ccWO1SKiqGzOf8PxFN8v2fo+uccRXEQ nscxoG/J/T2CVHoIp4SC5ljNdA4fg/khZDUomsjTSfe9Ouyzl8loxmTjYw8SnxHAiKScg5 sQS8CPdXDZUKvFG+0u5Ld3coVNUyVN2oBur3H/rZIHYqCtc9JUfYY6E0haeGAQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=hgTvjL9+; 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=none) header.from=gmail.com Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qekrj-000222-UL; Fri, 08 Sep 2023 19:26:19 -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 1qekri-00021a-A4 for guix-devel@gnu.org; Fri, 08 Sep 2023 19:26:18 -0400 Received: from mail-ed1-x542.google.com ([2a00:1450:4864:20::542]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qekrf-0008CB-T0 for guix-devel@gnu.org; Fri, 08 Sep 2023 19:26:18 -0400 Received: by mail-ed1-x542.google.com with SMTP id 4fb4d7f45d1cf-52683da3f5cso3356376a12.3 for ; Fri, 08 Sep 2023 16:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694215574; x=1694820374; darn=gnu.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=MpCAeFSEKXT8ki5QiK+Ezu1ica80T+1ZfHrcUfcjSjY=; b=hgTvjL9+Ac0jW9uIIlSKVCVxrk+pfkKs0Iml4Ar/dCSLunn61xM1LuKco6v1rtDBTh kF1x+18UMwuEpYWtldn0bdLh3oFWk6v3cKlSZcB4lV7HmzDhLXTE5tEJ7VmWi+PQAYCB uk7PSj4AVWigViFAYNzgTeHTT3Rd4qElVzJeTLW1VnRuNQGgW5sJjsbh49DB5HakZ2u0 0kCFgO4j7FgphgjfuQgs9evfjryMWzd8os1CZ/cSVJ/QvLoMpwBcVF63Rmx6Mm1JVcRg BYMeBzToDs9LeZVqQhYR2vWF4y0r9GdwraRR43lE7r+l1ud42Tm8lADMDVwlKFQIT9/w 9Fnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694215574; x=1694820374; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=MpCAeFSEKXT8ki5QiK+Ezu1ica80T+1ZfHrcUfcjSjY=; b=nl+g35C7hYgeRD0hsPS6hkDEvSfAWf5nWi6zPmBxisrWGM5DVegQaV7M3L0s+nx5Vg 8roy5HocA+USOiSsjLgKJs8/jhENw4wdMZqyFCLoHIAq39gqtJpdVL7EiWNENShucktn +Ah1wWfxDlnPcz99J8S8sjrC+0+JgPmL/ScuSWJ3W+3dIqn3TOL3FxPI6ielwxuK/1s8 /iuvo3qxAvYeLM3Gmf25YKdAlBwsqLo1DjHrreApV9wNHvEE4K+MLbFYWseRBXW1PvzH nOICEu2meeDDoP8ra4gqVyHxCIra7cKwIvtkHo7izWqmkHtsggMB3gs+Md+QD3mBkgKD XWog== X-Gm-Message-State: AOJu0Yz+yJZnjgvFOYRm8FBwlNn+3Am89u8IjxKuchI69Vyd9M4LzbUy 9jZAN+KxxtIS4yiLWAhPjx8= X-Google-Smtp-Source: AGHT+IEL9KZ4ukKAGKMe+aIiRMnxBLTE+p+8oN03bW3zjhO3I9PPlbY1OPfqpuAaYWp0KoeZ1cR50Q== X-Received: by 2002:a17:906:2101:b0:9a1:d25c:55e3 with SMTP id 1-20020a170906210100b009a1d25c55e3mr3433131ejt.16.1694215573924; Fri, 08 Sep 2023 16:26:13 -0700 (PDT) Received: from lumine.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id p21-20020a170906b21500b0099bcb44493fsm1619216ejz.147.2023.09.08.16.26.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Sep 2023 16:26:12 -0700 (PDT) Message-ID: <4c85b742e29ebbf7fe3cde3f72961269ec26218c.camel@gmail.com> Subject: Re: How can we decrease the cognitive overhead for contributors? From: Liliana Marie Prikler To: Ricardo Wurmus Cc: Attila Lendvai , Andreas Enge , Katherine Cox-Buday , guix-devel@gnu.org Date: Sat, 09 Sep 2023 01:26:11 +0200 In-Reply-To: <87tts44d2y.fsf@elephly.net> References: <87sf7o67ia.fsf@elephly.net> <9269133a74e06bfc5ee5bfeee0342ba2f5beaeb1.camel@gmail.com> <87tts44d2y.fsf@elephly.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4 MIME-Version: 1.0 Received-SPF: pass client-ip=2a00:1450:4864:20::542; envelope-from=liliana.prikler@gmail.com; helo=mail-ed1-x542.google.com 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 X-Migadu-Scanner: mx2.migadu.com X-Spam-Score: -5.58 X-Migadu-Queue-Id: DE6C234B28 X-Migadu-Spam-Score: -5.58 X-TUID: a3yzyKy+9JaS Am Freitag, dem 08.09.2023 um 22:24 +0200 schrieb Ricardo Wurmus: >=20 > Liliana Marie Prikler writes: >=20 > > > On Github, Pull Request branches are like our WIP branches.=C2=A0 The= y > > > are how we arrive at acceptable changes.=C2=A0 Picky people like me > > > would then go back and write new atomic commits for the effective > > > diff, but in my role as a reviewer I usually rebase, squash, and > > > merge. > > >=20 > > > This workflow is more familiar to some and alienating to others, > > > but both of these workflows would work fine for Guix.=C2=A0 But today > > > our tools can only accommodate *one* workflow.=C2=A0=C2=A0 > > I'd imagine that rebase, squash and merge would exacerbate the > > workload on the committer side and I think that most popular > > projects on those forges already experience similar effects to us > > despite folks just merging the requests as-is and in part even > > getting paid by big tech for doing so. >=20 > Look, I=E2=80=99m relating merely my work experience here as someone who > regularly reviews pull requests on Github.=C2=A0 Github has buttons for > =E2=80=9CRebase and merge=E2=80=9D, =E2=80=9CSquash and merge=E2=80=9D, a= nd =E2=80=9CCreate a merge commit=E2=80=9D, > so that part is automated. >=20 > I=E2=80=99m not saying that this is the workflow we should adopt.=C2=A0 I= =E2=80=99m saying > that these platforms =E2=80=94 for better or worse =E2=80=94 encourage *d= ifferent* > workflows, and for some this is what they are most comfortable with. How many different workflows are those? In my opinion, the one that folks typically refer to when mentioning comfort is 1. git branch 2. git push elsewhere [ long conversation using the forge's blessed UI ] ?. git merge Fair enough, as a committer you get the option of cherry-picking, rebasing, or whatever else instead of a merge, but the UI support for those alternatives ranges from "okay, I guess" to "you know how to do this by command line, don't you?" and "this change will be marked as rejected even though you actually merged it". Whenever you're using these platforms, you are being nudged into its happy path, just as the contribution via email model really makes it hard to just type "git merge" and expect success =E2=80=93 you do need git am at some point. > Must we force a single workflow on everyone, even if our track record > in reviewing and merging doesn=E2=80=99t clearly show that our way is > superior? Again, define superior. > Recall that the reason for my response at this point in the thread is > your statement: >=20 > > Hiding obsolete versions of a pull request is in practice > > implemented either by pushing more commits on top of the existing > > one, often with dubious commit messages or by force-pushing a > > branch, neither of which is an acceptable solution for Guix. >=20 > I=E2=80=99m trying to convey that this workflow is similar to how we woul= d > push to wip-* branches and informally discuss open issues out of > band. (And even in that scenario, we are rather limited by the way > our shared repository with all-or-nothing permission management > works.) I think this is a bit of an apples to oranges comparison. Even for our wip branches, we mostly adhere to the guidelines that govern master, it's mostly the rule regarding breaking changes that is relaxed. We wouldn't have well-functioning wip branches if those forewent *all* communication efforts. The only common ground I can see is that all feature branches =E2=80=93 or at least those that don't die =E2=80=93 get m= erged to the main branch in either workflow. Cheers