RFE: use patchwork to submit a patch

Stephen Finucane stephen at that.guru
Sun Oct 13 00:16:22 AEDT 2019

On Thu, 2019-10-10 at 10:41 -0400, Konstantin Ryabitsev wrote:
> Hi, all:
> I would like to propose a new (large) feature to patchwork with the goal 
> to make the process of submitting a patch easier for newbies and people 
> generally less familiar with patch-based development. This was discussed 
> previously on the workflows list: 
> https://lore.kernel.org/workflows/20190930202451.GA14403@pure.paranoia.local/

I'll echo Daniel's sentiments that I like the idea of a git-to-email
bridge, but that I'm not sure if that should belong in Patchwork core.
I too am open to being convinced but before we get to anything like a
solution though, I'd like to identify the problem(s) you're trying to
solve. From reading this thread, it seems there are three separate
issues issues intertwined here.

 * Corporate email is often broken, meaning people have to jump through
   hoops to simply submit a patch, if it's even possible. [1]
 * Encoding metadata in emails has to be done in an ad-hoc, freeform
   fashion, through special headers, tags in the subject or specific
   annotations in the body. This requires reading large contributors
   guides before sending anything.
 * Using CLI tools in general is hard for newbies (?)

Asssuming those are correct, I'd like to challenge some of them :)
There isn't a whole lot that can be done about broken email, at least
until JMAP becomes a thing (it's done over HTTP so that could help. Or
not. idk), but I'm not sure about the other two. I don't know what kind
of metadata would be needed to submit a patch to a random subtree of
the kernel, but I assume the metadata exists for a reason? If so, is
this actually something we can tackle via a UI or CLI without producing
custom workflow tools for every single project and if not, can we
actually solve this particular issue? Personal, I would consider
reading the contributor guide a minimum barrier to entry, as without
this you're simply transferring work from contributors to (often
overworked) maintainers but I do acknowledge that it's easy for me to
say that since I know how to do this stuff already. The same idea
applies to the idea of not using CLIs. Is there an statistically
significant amount of people that would be able to submit useful
changes but can't use a CLI tool? I know you can get away without using
a terminal for traditional Windows development or web development, but
surely terminal knowledge is a prerequisite for almost everything else?

What I'm trying to get at here is figure out if (a) this is something
that can really benefit from living in Patchwork, (b) this is something
that needs a UI, (c) this is something's that necessary full stop (vs.
just waiting for projects to switch to GitLab or Gerrit or whatever new
cool ends up being). If we can figure that out, we can look into how we
can go about implementing stuff.


[1] I've multiple personal examples of this, from having to ask IT
during my Intel days to remove automatic legal signatures to
outlook.com refusing to respect message-id's, resulting in broken
threading at a minimum. Thankfully I don't have to jump through those
hoops at Red Hat but yeah, eew.

More information about the Patchwork mailing list