guix-devel
[Top][All Lists]
Advanced

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

Re: How can we decrease the cognitive overhead for contributors?


From: Andreas Enge
Subject: Re: How can we decrease the cognitive overhead for contributors?
Date: Wed, 23 Aug 2023 20:03:00 +0200

Hello,

Am Wed, Aug 23, 2023 at 10:27:31AM -0700 schrieb Felix Lechner via Development 
of GNU Guix and the GNU System distribution.:
> >      I can't ever seem to get the GNU style commit messages correct.
> Neither can I. The style apparently helps with automated maintenance
> of the changelog, but I do not understand why a changelog is useful
> for a rolling release model.

personally, I find them super helpful to grep through commit messages
to find changes, like when a file was touched for the last time (now
I think that git wizards will have a better solution; but you get the
idea). Or when a package was added. Or updated to a specific version.
I have ended up adopting the style for all of my other coding projects
as well because I find it so useful.

For simple updates, there is etc/committer.scm. I use it for package
updates. It would be nice if it could handle more cases, such as removing
patches.

> >      I don't use the email-based patch workflow day-to-day
> Yeah, I can deal with small inline patches, but Guix requires changes
> to be split into many tiny commits.

This is explained here:
   https://guix.gnu.org/de/manual/devel/en/html_node/Sending-a-Patch-Series.html

I also cannot remember what to do when there is more than one patch,
so I follow this approach every time. (Well, this is a white lie; mostly
I propose single patches or work in a branch...)

All in all, I think better tooling will be welcome (but is not a joy to
write).

Am Wed, Aug 23, 2023 at 10:25:58AM -0600 schrieb Katherine Cox-Buday:
> * Contributing to Guix is not for you
> * It's OK to make lots of mistakes

Definitely "no" to the first one, and "yes" to the second one!
I think that even when one only contributes from time to time, but
regularly, habits will form and mistakes disappear.

> * We could support a managed web-based workflow

I am all for it if it supplements the email based workflow (every
time I need to do a modern style pull request type action, I am
completely out of my depths and lost in the web interfaces...).
But someone would have to write and maintain them...

> * Encourage upstream communities like "Guix 'R Us"

Why not, but they also require management (adjusting the schedules
of several busy people, for instance).

Andreas




reply via email to

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