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
