unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Arun Isaac <arunisaac@systemreboot.net>
To: "Giovanni Biscuolo" <g@xelera.eu>,
	"Ludovic Courtès" <ludo@gnu.org>,
	"Guix Devel" <guix-devel@gnu.org>
Cc: GNU Guix maintainers <guix-maintainers@gnu.org>
Subject: Re: On commit access, patch review, and remaining healthy
Date: Fri, 10 Jun 2022 01:20:29 +0530	[thread overview]
Message-ID: <87bkv1lipm.fsf@systemreboot.net> (raw)
In-Reply-To: <87tu8viix0.fsf@xelera.eu>


Hi Giovanni,

>> Guix has very high coding standards
>
> Do you think other software distribution do have less high coding
> standards?

I meant that Guix has very high coding/packaging standards in the
following senses:

- We prefer to not bundle dependencies. Tracking out bundled
  dependencies, git submodules, etc. and figuring out how to rewire
  everything so it works with unbundled dependencies can be really
  tricky for some packages.
  
- We build strictly from source.

- We aim to package tests for all packages.

- We have strict conventions for commit messages. Our commit message
  Changelog is a strange dated practice from the time before good
  version control systems. I can live with it, but not everyone likes
  it. Let's just say I've heard complaints about it offlist.

- We don't just list the main license of a package. We trace out the
  license of each and every file, if they are different from the main
  license.

- Our synopses and descriptions are not casually copy-pasted from the
  project website. We try to rewrite and improve on them if necessary.

- We have to be careful about pushing changes that will cause too many
  rebuilds. We have a core-updates process for that.

I could go on forever, but you get the idea. I do agree with most of
these coding standards, and have no problem with following them. But, it
does add some pressure to the process.

I don't have much experience with other distributions except for Arch
Linux and that too only with the AUR (Arch User Repository). The AUR was
more of a wiki than a centrally curated repository. Anyone can
contribute packages, and there is no review. Most packages don't run
tests, and the standards are generally low.

>> but that means that there is a high cost of failure
>
> please can you expand on this?  What is that cost of failure?

The cost of failure is mostly in the mind. A commit is something that
has your name on it and lives on in the repo history *forever*. So, it
better be good. That's the pressure. I do have one or two commits in the
guix repo with badly borked commit messages.

>> and a pressure to live up to that high standard. This means that even
>> if I'm 99% sure of a commit, I tend to leave it to others because of
>> that nagging 1% doubt I have about some trivial aspect of the
>> patch. The 1% doubt could even be about really trivial things like
>> indentation or the name of a variable. In other words, perfectionism
>> causes paralysis.
>
> generally speaking I really understand your feeling (the "impostor
> syndrome" as Ludo' say) but please do not be paralyzed by this feeling,
> do /not/ have fear to make a mistake, we (pluralis majestatis :-D ) are
> not here to judge you

I know. ;-)

> specifically speaking, IMHO in cases like this you should send an
> email-reply to that bug (patch) explaining the 1% you are unsure of

Yeah, I would. But, often that 1% is too nitpicky to be worth
reporting. Sometimes, I fix the 1% myself and push. But often, I confess
that I just leave it to other committers.

>> This excessive self-doubt is created by feeling like one doesn't
>> "belong" in the elite community of Guix hackers
>
> I undestand there are many meanings of "elite" [1], but if it's an
> elite

I meant "elite" in the sense that Guix hackers are among the most
skilled programmers I've known.

> it is /for sure/ a very open group of persons

Definitely, I love the community! That's why I'm still here after all
these years!

Cheers! :-)
Arun


  reply	other threads:[~2022-06-09 19:51 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-02 15:10 On commit access, patch review, and remaining healthy Ludovic Courtès
2022-06-02 20:22 ` Brian Cully via Development of GNU Guix and the GNU System distribution.
2022-06-03 19:37   ` Ludovic Courtès
2022-06-03 21:17     ` Ricardo Wurmus
2022-06-07  7:08     ` Efraim Flashner
2022-06-07 15:11       ` Ludovic Courtès
2022-06-08 11:39         ` Efraim Flashner
2022-06-08 21:10           ` Ludovic Courtès
2022-06-20 12:53         ` Hartmut Goebel
2022-06-21 15:44           ` zimoun
2022-06-22  9:19             ` Munyoki Kilyungi
2022-06-02 20:32 ` Pier-Hugues Pellerin
2022-06-03 19:42   ` Ludovic Courtès
2022-06-02 21:35 ` Luis Felipe
2022-06-03  8:22   ` Feed on specific topic (public-inbox?) zimoun
2022-06-03 10:51     ` zimoun
2022-06-06 12:11 ` On commit access, patch review, and remaining healthy Arun Isaac
2022-06-06 21:43   ` Ludovic Courtès
2022-06-07  6:44     ` zimoun
2022-06-08  9:30       ` Giovanni Biscuolo
2022-06-14 12:24         ` zimoun
2022-06-15  7:01           ` Arun Isaac
2022-06-15  9:19             ` Ludovic Courtès
2022-06-19  6:55             ` Paul Jewell
2022-06-20 12:11               ` Arun Isaac
2022-06-15 15:11           ` Giovanni Biscuolo
2022-06-08 10:54     ` Giovanni Biscuolo
2022-06-09 19:55     ` Arun Isaac
2022-06-08  9:49   ` Giovanni Biscuolo
2022-06-09 19:50     ` Arun Isaac [this message]
2022-06-10 12:27       ` Giovanni Biscuolo
2022-06-10 15:03         ` Efraim Flashner
2022-06-10 16:10           ` Giovanni Biscuolo
2022-06-10 16:26           ` Giovanni Biscuolo
2022-06-10 15:03         ` Maxime Devos
2022-06-11  4:13         ` Thiago Jung Bauermann
2022-06-11  9:37           ` Ludovic Courtès
2022-06-14 11:54           ` zimoun
2022-06-14 15:54             ` Maxim Cournoyer
2022-06-15  6:46               ` Arun Isaac
2022-06-13 12:19         ` Arun Isaac
     [not found] <mailman.12124.1654864076.1231.guix-devel@gnu.org>
2022-06-12  8:18 ` Ricardo Wurmus
2022-06-12  9:42   ` Giovanni Biscuolo
2022-06-12 13:10     ` Maxime Devos
2022-06-13  9:34       ` Giovanni Biscuolo
2022-06-13 10:48         ` Maxime Devos
2022-06-13 14:21           ` Giovanni Biscuolo
2022-06-12  8:21 ` Ricardo Wurmus

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=87bkv1lipm.fsf@systemreboot.net \
    --to=arunisaac@systemreboot.net \
    --cc=g@xelera.eu \
    --cc=guix-devel@gnu.org \
    --cc=guix-maintainers@gnu.org \
    --cc=ludo@gnu.org \
    /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).