Here you go: https://github.com/haskell/cabal/pull/8176 If there are review comments, I guess I will be copying them in emails to you and you will be sending me replies and new commits to paste into the pull request? All the best, Mikolaj On Sat, May 28, 2022 at 8:55 PM Vilius Panevėžys wrote:

Hi Mikolaj, thank you for the prompt reply!

On Sat, 28 May 2022 17:10:24 +0200 Mikolaj Konarski wrote:

...

Would you like to create a pull request on github with these changes to help us see them in context, e.g., whether they merge cleanly and which branch, and to help us credit you properly?

I don't use GitHub, so I hope it's not too much trouble to just `git am` the patches. I've rebased the patches on master today, so they should apply cleanly. However, if it turns out you need me to make any revision - let me know.

My appreciation goes to all the people who have put in the time and effort into creating the user guide (not to mention Cabal itself!).

On Sat, 28 May 2022 14:30:30 -0600 emilypi@cohomolo.gy wrote:

gonna be completely honest - i appreciate the patches but i'm not going to go through the labor of applying something this trivial. Unless not using Github is a conscientious protest against ICE or their military contracts or the like , i'm liable to just reject email patches that are not security related or critical fixes on policy grounds.

I believe reliance on proprietary platforms is detrimental to free software [1]. Note, though, I was not trying to circumvent the preferred submission process as I mentioned in another email in this thread. Email has the lowest barrier to entry. By raising the barrier, drive-by contributions are discouraged. Not only are they useful on their own, any drive-by contribution may just be the first of many. Unless it doesn't happen. Imagine you came to volunteer at a charity event. It happens to be hosted at a corporate office that has otherwise nothing to do with the charity. However, the corporation requires every volunteer to enrol in their loyalty programme (which includes analysing and accepting the terms of service and privacy policy whatever it may be) before they are allowed on premises. I would find that obnoxious. [1] https://drewdevault.com/2022/03/29/free-software-free-infrastructure.html

Hi Vilius,

I did not know a PR is required.

It is. PRs automate a lot of things. Ci is run, reviews are collected, including comments to specific lines, and responded to via text and via code and marked as done. The patch is automatically rebased and merged. Backports are created, etc., etc.,

I presumed patches via email are acceptable as they often are in projects that use mailing lists, especially a -devel list.

I think the disconnect is that today very few of cabal developers are on this mailing list and there is very little traffic so you can't expect a dev discussion on the list or a crowd of helpful devs to share the chores. We should probably close the list to avoid such misunderstandings. However, in case github/gitlab/etc. break down, are censored, cancelled and/or betray their social mandate, we have a low-tech and open alternative, which was proven to work adequately in the Stone Age, so should work in the post-apocalypse as well. However, I'd rather use non-stone tools for as long as possible. Cheers, Mikolaj