Re: Not usable email content encoding

[Jonathan Wakely <jwakely.gcc@gmail.com>]

On Wed, 18 Mar 2020 at 21:54, Jim Wilson wrote:
>
> I'm one of the old timers that likes our current work flow, but even I
> think that we are risking our future by staying with antiquated tools.
> One of the first things I need to teach new people is now to use email
> "properly".  It is a barrier to entry for new contributors, since our
> requirements aren't how the rest of the world uses email anymore.
> LLVM has phabricator.

Which is horrible.

> Some git based projects are using gerrit.

Which I looked into previously and decided I didn't like it. If I
recall correctly, gerrit has to "own" the repo, and so it's only
possible to commit to the repo by pushing to gerrit first, then
getting the patch approved. That is fine for write-after-approval, but
adds a step for maintainers who can approve their own changes.

I think it also only very recently gained the ability to group a
series of patches together, as it wants a single commit per review.


> Github and gitlab are useful services.  We need to think about setting
> up easier ways for people to submit patches, rather than trying to fix
> all of the MUAs and MTAs in the world.

There's also https://pagure.io/pagure which is Free Software.

I think it would be great if one of those forge services could be set
up to run *in parallel* to our existing workflow, so that we can
accept pull requests there without forcing all work to go through it
(like gerrit). New contributors who are used to the GitHub model could
submit pull requests there, and maintainers could merge them into the
repo with the click of a button. For significant changes it's more
likely maintainers would pull the branch into their local repo, test
it, and then push manually. But if we had a CI service testing pull
requests (like Travis CI does for GitHub) and a pull request was shown
to introduce no regressions then it could be merged with a single
click.