[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, 30 Aug 2023 18:53:47 +0200 |
Hello Katherine,
thanks for your summary, which contains many points I would agree with and
actionable items (disclaimer: I do not promise to act on them).
Am Wed, Aug 30, 2023 at 10:11:02AM -0600 schrieb Katherine Cox-Buday:
> Here's my understanding of the process to contribute a patch:
My process is actually a bit easier...
> 5. Create a git worktree for your patch
> 6. Run `./bootstrap`, then `./configure --localstatedir=/var
> --sysconfdir=/etc`
You can drop 6 assuming you do not create a new .scm file.
Instead of 5, I usually just branch off from master, or simply work on
master itself (for instance, for a simple package update). In the latter
case, after creating and sending the patches, a
"git reset --hard origin/master" drops all my work.
> 8. Make your changes
> 9. Build to ensure your changes are workable.
> 10. Try and determine how your changes should be factored into individual
> commits (sometimes it's not always so clear when changing two things
> might
> need to be done atomically).
> 11. Try and get each commit message close to correct and commit.
Usually I start with 10, and then make the changes incrementally.
For instance, today I wanted to update a package and change an input.
I simply changed the input first, built and made a commit.
And then I updated the package, built and invoked ./etc/committer.scm.
Admittedly, I also do not do all the checks you mention, like closure
sizes or reproducibility of the builds.
Andreas
Re: How can we decrease the cognitive overhead for contributors?, Simon Tournier, 2023/08/24
Re: How can we decrease the cognitive overhead for contributors?, Csepp, 2023/08/24
Re: How can we decrease the cognitive overhead for contributors?, Maxim Cournoyer, 2023/08/26