> Dear Guix,
> 
> I've just blown up Guix's debbugs by opening (and then closing) 33 bugs
> instead of sending a 33-commits patch series.
> 
> I've also seen that there is a huge discussion on the cognitive overhead
> of contributing. I will read it as soon as I can spare more time on this.
> 
> I find git email's workflow extremely frustrating and confusing. I know
> it works for most of you who actually commit, but I would like to point
> out that I'm one more person to be tripped by its complexity, and who
> cares enough to say so here. There are probably even more people who
> don't speak up.

I have done that too, but I think the problem is caused by debbugs, not
by git send-email.

> Therefore, there is a huge cost in keeping up using it: less people will
> be able to provide patches, and software will get stale.
> 
> For example, ou current Go version is 1.17 ! From 2021 ! The current is
> 1.21. I suspect that if contributing was easier, we wouldn't have a 2
> years delay in our versions.

I don't think so, because we are already getting more contributions than
are getting reviewed. If contributions were easier to send but reviewing
them wouldn't change we'd just have that 2 years of delay in applying
the patches.

> [...]
>
> Before anybody tries to explain to me that git send-email is easier than
> I think, what you have to beat is:
> git remote add guix-patches WHATEVER #only once
> git push -u guix-patches master:some-unique-name
> 
> You can then push, pull, rebase, whatever, from the command line (or
> magit in my case), without leaving your dev context. Can't be easier
> than that.

It would be possible to have a git send-email -based workflow that would
look something like this:

$ git clone ...
[ make changes ]
$ git send-email origin/master
[ get feedback, edit and rebase ]
$ git send-email origin/master --in-reply-to=msgid
[ repeat ]

We could even have a script that would submit changes and with that the
workflow could be as simple as:

$ git clone ...
$ ./script new
[ make changes ]
$ ./script send
[ get feedback, edit and rebase ]
$ ./script send
[ repeat ]

The problem is not using email, it is that the tooling we currently have
or recommend requires doing more manual and error-prone steps than is
actually necessary.