From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id GEocDq81+2R2PgEA9RJhRA:P1 (envelope-from ) for ; Fri, 08 Sep 2023 16:54:39 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id GEocDq81+2R2PgEA9RJhRA (envelope-from ) for ; Fri, 08 Sep 2023 16:54:39 +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 EFEC5D8DE for ; Fri, 8 Sep 2023 16:54:38 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=elephly.net header.s=zoho header.b=b621kmln; 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=none; arc=pass ("zohomail.com:s=zohoarc:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1694184879; 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=mztlqXvHVnQQXORXlrmvDIVRsetjZxDO5sz78uo+BBM=; b=psZY+XecOkg7vMM/JowmbBciSuoIIZC3gq2h0wfCFS8iNqUll4j9rd2DmaRtUQpvJDPtWk gN6SgKdksG7hniSZi/GGOgdQ0d2JiXIOaV1OjzPnpkQqwtQWqw5Hh5VMPmRJR3hrNFhJjf jMy8TYboi49wXRRw1+ke5kvj0AsF+6Nkw2azdqYa7Im6tY2zRHm9vh8MJ6uBVr8G1mWESB N3t8nKasoEsyaN/UwYtSl6ZRT+znEcwLIzUwI4xT9VW8bHV7bU4oEAYlG1Gj0q9ZQrtk9M PJAIZZgawGBF+2uWqvV4GDrGwy9UQS4ZNsfhHwV6K6v8ZjDK6BO76OtZ0DPGCw== ARC-Seal: i=2; s=key1; d=yhetil.org; t=1694184879; a=rsa-sha256; cv=pass; b=A82ghE8iwj5uJJy3r+7bxFS/2ppY3VLXH4JX+9sAeFCX8rlBXyfWF3F8s7rKAbKKy8TirB 5dxq7b4wP6Cwyo1d1zWBG4nQAaN93DsDjO/IUynZTg3sqf9UhqyFVC2lUYivqfJQhK4SCz FA8B3d3LYwSlg54w5CitmfXfaPOPMkPwHzOCQyy9GNEI0hc9dlhkMuMc4uYWxIWOIzlHiX C3IS2EuzOLmir6Df4/ET0+41qRzY/0RlXen1zK6IBdhbg7ElJkYTUuL5AnWDdZ/D08g7bx XU6b1QQRpes+jfM5Mnx57dtkZkW2HpCAUcUqSPAwgZzj8B+4s9VLbg7R3cBchQ== ARC-Authentication-Results: i=2; aspmx1.migadu.com; dkim=pass header.d=elephly.net header.s=zoho header.b=b621kmln; 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=none; arc=pass ("zohomail.com:s=zohoarc:i=1") Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qecs1-0005MK-Nv; Fri, 08 Sep 2023 10:54:05 -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 1qecs0-0005M5-3y for guix-devel@gnu.org; Fri, 08 Sep 2023 10:54:04 -0400 Received: from sender3-of-o58.zoho.com ([136.143.184.58]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qecrx-0002bh-8b for guix-devel@gnu.org; Fri, 08 Sep 2023 10:54:03 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1694184836; cv=none; d=zohomail.com; s=zohoarc; b=AsjSRcP7vwaKZMUwF0sXhz6AA0BgjFhRd/EHg84Ho2eurR4iVas444tYCNmBE/b+b6MM58EQTE2BbD+XvS9UtzhtWb4Y0hb7UB6EynHkVhmEwXn1yTYJbVXEIJjRGTJYPLb7ivaeerZ9QFfWBDQAo6FdOVHjShDl7qecVE9g/Rs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1694184836; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=mztlqXvHVnQQXORXlrmvDIVRsetjZxDO5sz78uo+BBM=; b=i1qVUGZMFbOHfxIg78w+RJ6B7VC94AfLFW784OY+s1d3n+RcOiV/vjL4GVtNQjGzH9J5L8jhE5orfdQivRRj22FObTb9J+MOA2k8SQQFdNt9vaVQ5t+FEeCNlt4FoR+vi09AIInIgMI2TyWwLw901IupHgpvDGQlW9y5zrOq8l0= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=elephly.net; spf=pass smtp.mailfrom=rekado@elephly.net; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1694184836; s=zoho; d=elephly.net; i=rekado@elephly.net; h=References:From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:In-reply-to:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=mztlqXvHVnQQXORXlrmvDIVRsetjZxDO5sz78uo+BBM=; b=b621kmlnzeQomgWtsLLxIqCtXCooD4UwhCtUjqs9RUbjad1Vg+ztRd6iNAgCiTE5 /SybVtyfeLQ9d6SJtQaEJr+400QQa+5Sqg+pZXPClPwceeTfJrzPo23ej0Fd+DdkH7R 6SF/WnNMGkw77KisS//pQqQE0PXuyHvuB4W5VKQM= Received: from localhost (133-122-142-46.pool.kielnet.net [46.142.122.133]) by mx.zohomail.com with SMTPS id 1694184832887708.3890777103798; Fri, 8 Sep 2023 07:53:52 -0700 (PDT) References: User-agent: mu4e 1.10.5; emacs 28.2 From: Ricardo Wurmus To: Liliana Marie Prikler Cc: Attila Lendvai , Andreas Enge , Katherine Cox-Buday , guix-devel@gnu.org Subject: Re: How can we decrease the cognitive overhead for contributors? Date: Fri, 08 Sep 2023 16:44:41 +0200 In-reply-to: Message-ID: <87sf7o67ia.fsf@elephly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External Received-SPF: pass client-ip=136.143.184.58; envelope-from=rekado@elephly.net; helo=sender3-of-o58.zoho.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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, 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: mx0.migadu.com X-Migadu-Spam-Score: -0.61 X-Spam-Score: -0.61 X-Migadu-Queue-Id: EFEC5D8DE X-TUID: dwQ3V+3B1QWf Liliana Marie Prikler writes: >> one fundamental issue with the email based workflow is that its >> underlying data model simply does not formally encode enough >> information to be able to implement a slick workflow and frontend. >> e.g. with a PR based model the obsolete versions of a PR is hidden >> until needed (rarely). the email based model is just a flat list of >> messages that includes all the past mistakes, and the by now >> irrelevant versions. > What the? If anything, emails are like a tree and discussions in most > forges are a single long list that's rarely well organized. Virtually > every mail client supports threads, whereas a certain one of the more > popular forges still refuses to do so. 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. I often have to review Github Pull Requests, and I don=E2=80=99t go commit = by commit by go through the diff and annotate the changes. I *read* the commits to get a sense for how the feature evolved and why changes were made, but the fact that new commits are pushed on top of the branch is not an obstacle in practice, because the commits don=E2=80=99t matter. (I know, it hurts me too, but I don=E2=80=99t make the rules, okay?) And in these review interfaces we can mark individual comments as resolved. So the flat list of changes with annotations *does* in fact provide a clearer organization than a tree of emails. Note also that we don=E2=80=99t usually review commits by starting one new thread for each issue we address, so we don=E2=80=99t benefit from automatic branching of sub-discussions. On Github, Pull Request branches are like our WIP branches. They are how we arrive at acceptable changes. 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. This workflow is more familiar to some and alienating to others, but both of these workflows would work fine for Guix. But today our tools can only accommodate *one* workflow. It happens to be the one I=E2=80=99m = used to, but let=E2=80=99s please not pretend that it=E2=80=99s inherently *bett= er* than the other. --=20 Ricardo FWIW: Mumi is the worst of both worlds as it flattens the email tree while not providing any of the review features that popular forges have. So the problem of outdated and repeated mistakes in a flat list becomes more pronounced there.