unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Raghav Gururajan <raghavgururajan@disroot.org>,
	Ryan Prior <ryanprior@hey.com>,
	Danny Milosavljevic <dannym@scratchpost.org>
Cc: Development of GNU Guix and the GNU System distribution
	<guix-devel@gnu.org>
Subject: Re: Questionable "cosmetic changes" commits
Date: Sat, 05 Dec 2020 01:47:51 -0500	[thread overview]
Message-ID: <87im9g4ukt.fsf@netris.org> (raw)
In-Reply-To: <cace69473f8551d4e2b89f412bfcdf12@disroot.org>

Hi Raghav,

"Raghav Gururajan" <raghavgururajan@disroot.org> writes:

> Yeah, my brain laterally connects fields of different package
> definitions. Like a spread-sheet, where each columns are different
> package definitions and each row is a fields of a package's
> definition.
>
> For example, if column 1 is glib and column 2 is gtk+, my brain spots
> pattern or errors when [arguments] field of both the packages are in
> the same row. Let's say [arguments] field of glib pack-def (column) is
> in 4th place (row); and; if the 4th place (row) of gtk+ pack-def
> (column) is [propagated-inputs]; my brain goes haywire. So I first do
> the cosmetic change of rearranging the fields of gtk+ pack-def to
> match with pack-def of gtk+. This is just one example.

If your goal is to make the ordering of package fields more consistent
across Guix -- which is something that I could support -- I can report
that your commits are making that problem worse, not better.

One of the common features of your "cosmetic changes" commits is that
they all move the 'home-page' field from its conventional place above
the 'synopsis' to below the 'description', if it wasn't there already.

I just hacked up a little script to determine which ordering is more
common.  For simplicity, it only considers top-level declarations of the
form (define-public <pkg-name> (package ...)).  Out of 11446 packages of
that form in gnu/packages/*.scm, 88% of them (10078) have the
'home-page' field above the 'description' field.

So, if consistency of ordering is your goal, you're going in the wrong
direction.

* * *

Meanwhile, you've only provided a rationale for 1 out of 3 of the kinds
of changes made in these commits.

Do you have an explanation for why you are removing comments in your
"cosmetic changes" commits?  For example, the following two commits
remove comments that explain why 'propagated-inputs' are needed:

https://git.sv.gnu.org/cgit/guix.git/commit/?id=c3264f9e100ad6aefe5216002b68f3bfdcf6be95
https://git.sv.gnu.org/cgit/guix.git/commit/?id=416b1b9f56b514677660b56992cea1c78e00f519

What's your rationale for doing this?  Am I the only one here who finds
this practice objectionable?  It's not even mentioned in the commit logs.

       Mark


  parent reply	other threads:[~2020-12-05  6:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-02 18:55 Questionable "cosmetic changes" commits Mark H Weaver
2020-12-02 20:13 ` Ryan Prior
2020-12-02 21:27   ` Tobias Geerinckx-Rice
2020-12-02 22:22   ` Mark H Weaver
2020-12-03  3:16   ` Bengt Richter
2020-12-02 21:33 ` Hartmut Goebel
2020-12-04  2:08 ` Raghav Gururajan
2020-12-04  3:30   ` Ryan Prior
2020-12-04  3:58     ` Raghav Gururajan
2020-12-04 15:12       ` Danny Milosavljevic
2020-12-05  6:47       ` Mark H Weaver [this message]
2020-12-05  7:06         ` Mark H Weaver
2020-12-05 20:37       ` Raghav Gururajan
2020-12-05 21:54         ` Christopher Baines
2020-12-05 23:42           ` Bengt Richter
2020-12-20  7:07           ` Raghav Gururajan via Development of GNU Guix and the GNU System distribution.
2020-12-05 23:29         ` Cosmetic changes commits as a potential security risk (was Re: Questionable "cosmetic changes" commits) Mark H Weaver
2020-12-20  6:55         ` Questionable "cosmetic changes" commits Raghav Gururajan via Development of GNU Guix and the GNU System distribution.
2020-12-20  7:00         ` Cosmetic changes commits as a potential security risk (was Re: Questionable "cosmetic changes" commits) Raghav Gururajan via Development of GNU Guix and the GNU System distribution.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87im9g4ukt.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=dannym@scratchpost.org \
    --cc=guix-devel@gnu.org \
    --cc=raghavgururajan@disroot.org \
    --cc=ryanprior@hey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).