From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id yEd1IHityV/bPAAA0tVLHw (envelope-from ) for ; Fri, 04 Dec 2020 03:31:04 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id ALlIHHityV+kcAAAB5/wlQ (envelope-from ) for ; Fri, 04 Dec 2020 03:31:04 +0000 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 B90A9940430 for ; Fri, 4 Dec 2020 03:31:03 +0000 (UTC) Received: from localhost ([::1]:41762 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kl1oE-0003X5-LM for larch@yhetil.org; Thu, 03 Dec 2020 22:31:02 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40024) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kl1nx-0003Sg-Ip for guix-devel@gnu.org; Thu, 03 Dec 2020 22:30:45 -0500 Received: from 102d.relay.hey.com ([204.62.115.202]:42411) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kl1nv-0003t6-FV for guix-devel@gnu.org; Thu, 03 Dec 2020 22:30:45 -0500 Received: from hey.com (bigip-vip-new.rw-ash-int.37signals.com [10.20.0.24]) by 102.relay.hey.com (Postfix) with ESMTP id 25F6F81E11; Fri, 4 Dec 2020 03:30:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hey.com; s=heymail; t=1607052642; h=from:from: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; bh=SXcoIvgJ7XaIT1QHWo8m8lDNPNt5DRY0b+f1p4hk6p0=; b=jWL93SIbfCCY5yWRZ3Rm+JvmovPSxKmQRccJpKecSJIugi0lStE+BJ57irm2LISfw2upIW FE9YA8X+HZkTzANtK5qgjjMgQpjVDn5fB9AAzTSW/ANl8xvXKexWM7vctArsKa0FzTJeKk WApfEDhfRQdcvGKgQ1qzuU/C2JLd23/PScrob3QFtJXT8mH0OUUOW80dLLGHvZu7YNHnju HBo+OI3B7b3SPIH36ZEy3WG1p3aLzkYQDKWc7SutLqTvKg27qWXtDdO0eLq9UG8RHynWd+ LGd/uAKKGxmDuAvGMcsdczZDUQ6M/TQxbk/LhQY7lg7ZjKFJd/BE36vgg+sQPw== Date: Fri, 04 Dec 2020 03:30:40 +0000 From: Ryan Prior To: Mark H Weaver , Danny Milosavljevic , Raghav Gururajan Cc: Development of GNU Guix and the GNU System distribution Message-ID: In-Reply-To: Subject: Re: Questionable "cosmetic changes" commits Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5fc9ad611eba8_260b2df0101860"; charset=UTF-8 Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=204.62.115.202; envelope-from=ryanprior@hey.com; helo=102d.relay.hey.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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.23 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" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.49 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=hey.com header.s=heymail header.b=jWL93SIb; dmarc=pass (policy=quarantine) header.from=hey.com; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: B90A9940430 X-Spam-Score: -2.49 X-Migadu-Scanner: ns3122888.ip-94-23-21.eu X-TUID: GCRXfwhmPfDP ----==_mimepart_5fc9ad611eba8_260b2df0101860 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On December 4, 2020, Raghav Gururajan =0D wrote:=0D > I can tell you that those cosmetic changes I made were 100%=0D > irrational, useless and noisy.=0D =0D That's certainly a way to frame it, but I'd like to hold some space for=0D= the idea that the things we neuroatypical people do to manage and=0D satisfy our own unusual perspectives are not irrational or useless if=0D they make sense to us and serve a purpose for us.=0D =0D > Due to [clinical conditions], if the packages I am editing is not it=0D= > in a specific way, I am unable to focus properly. That too, if I am=0D > working on multiple package definitions and if each pack-defs are=0D > arranged in different way, it is very very hard for me.=0D =0D That is an interesting use-case I hadn't considered, but a valid one,=0D and it gives me ideas. I'm going to experiment with some tools to make=0D= this feasible.=0D =0D Consider the tooling for Unison[1] which reduces code churn in a number=0D= of unique ways.[2]=C2=A0 It can store programs as abstract syntax trees=0D= rather than plain text files, and it's content-addressed, referring to=0D= functions by their hashes rather than their fixed names. As a programmer=0D= that gives you the freedom to choose names and language syntax that suit=0D= you without imposing on others to follow suit.=0D =0D Due to the functional paradigm and technical structure of Guix, I think=0D= we can build some of the same capabilities in our tooling. Like Unison=0D= functions, our package definitions are reduced to a declarative content-=0D= addressed form, from which a textual definition could be generated again=0D= using a reverse process. By such a process, you & I could edit package=0D= definitions in whatever textual form suits us individually without=0D having to agree on anything, not even the names of symbols. Then we can=0D= use a tool to automatically canonicalize our code into the form most=0D widely acceptable to the community when it's time to submit a patch.=0D =0D Taking this idea to its logical conclusion & building on Guile's multi-=0D= language-syntax paradigm, I can picture using a futuristic tool to edit=0D= package definitions in Emacs lisp or JavaScript, again without requiring=0D= that anybody upstream adopt those languages or even recognize that I'm=0D= using them.=0D =0D I'll see what I can hack together for a na=C3=AFve implementation of this= =0D concept and present it for review.=0D =0D > Moving forward, I will try hard not to do this. But can I ask you all=0D= > to allow these cosmetic commits for my existing projects (i.e. commits=0D= > from wip-desktop and pidgin patch-set) please?=0D =0D It doesn't bug me, but I know it does bug other people and imagine we=0D want to avoid creating unnecessary review work for people who follow the=0D= commit stream.=0D =0D > I understand that these commits were a burden to everyone and my=0D > sincere apologies for that.=0D =0D I appreciate the grace and consideration you brought to your response &=0D= all your contributions to Guix!=0D =0D =0D [1] https://www.unisonweb.org=0D [2] https://www.unisonweb.org/2020/04/10/reducing-churn/#definitions-=0D getting-renamed-or-moved=0D ----==_mimepart_5fc9ad611eba8_260b2df0101860 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D
=0D
=0D
On December 4, 2020, Raghav Gururajan <raghavgururajan@disroot.= org> wrote:
I can tell you that those cosmetic change= s I made were 100% irrational, useless and noisy.

Th= at's certainly a way to frame it, but I'd like to hold some space for the= idea that the things we neuroatypical people do to manage and satisfy ou= r own unusual perspectives are not irrational or useless if they make sen= se to us and serve a purpose for us.

Due to [cli= nical conditions], if the packages I am editing is not it in a specific w= ay, I am unable to focus properly. That too, if I am working on multiple = package definitions and if each pack-defs are arranged in different way, = it is very very hard for me.

That is an interesting = use-case I hadn't considered, but a valid one, and it gives me ideas. I'm= going to experiment with some tools to make this feasible.

Consid= er the tooling for Unison[1] which reduces code churn in a number of uniq= ue ways.[2]=C2=A0 It can store programs as abstract syntax trees rather t= han plain text files, and it's content-addressed, referring to functions = by their hashes rather than their fixed names. As a programmer that gives= you the freedom to choose names and language syntax that suit you withou= t imposing on others to follow suit.

Due to the functional paradig= m and technical structure of Guix, I think we can build some of the same = capabilities in our tooling. Like Unison functions, our package definitio= ns are reduced to a declarative content-addressed form, from which a text= ual definition could be generated again using a reverse process. By such = a process, you & I could edit package definitions in whatever textual= form suits us individually without having to agree on anything, not even= the names of symbols. Then we can use a tool to automatically canonicali= ze our code into the form most widely acceptable to the community when it= 's time to submit a patch.

Taking this idea to its logical conclus= ion & building on Guile's multi-language-syntax paradigm, I can pictu= re using a futuristic tool to edit package definitions in Emacs lisp or J= avaScript, again without requiring that anybody upstream adopt those lang= uages or even recognize that I'm using them.

I'll see what I can h= ack together for a na=C3=AFve implementation of this concept and present = it for review.

Moving forward, I will try hard n= ot to do this. But can I ask you all to allow these cosmetic commits for = my existing projects (i.e. commits from wip-desktop and pidgin patch-set)= please?

It doesn't bug me, but I know it does bug o= ther people and imagine we want to avoid creating unnecessary review work= for people who follow the commit stream.

I unde= rstand that these commits were a burden to everyone and my sincere apolog= ies for that.

I appreciate the grace and considerati= on you brought to your response & all your contributions to Guix!
=

[1] https://www.unisonweb.org
[2] https://www.unisonweb.org/20= 20/04/10/reducing-churn/#definitions-getting-renamed-or-moved
=0D
=0D =0D =0D
=0D =0D =0D ----==_mimepart_5fc9ad611eba8_260b2df0101860--