guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On commit access, patch review, and remaining healthy


From: Arun Isaac
Subject: Re: On commit access, patch review, and remaining healthy
Date: Fri, 10 Jun 2022 01:20:29 +0530

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 via email to

[Prev in Thread] Current Thread [Next in Thread]