Re: RFE: use patchwork to submit a patch

[Stephen Finucane <stephen@that.guru>]

On Sat, 2019-10-12 at 14:16 +0100, Stephen Finucane wrote:
> 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/

[top posting, sort of]

After writing this, I reopened my email client and noticed a lot of
replies that hadn't been there before. Stupid client/email provider
(I'm not sure who's to blame). It _seems_ like I'm not the only one
questioning the need for a point and click patch submission format, but
that doesn't mean there isn't some work we can do here. Previously,
Patchwork had the stated goal of aquiring the ability to reply to
patches via the web UI a lá Google Groups. If email is really an issue,
what about if we added that functionality along with the ability to
POST patches via the REST API? That would mean people would be able to
submit patches via e.g. 'git pw series submit' and then reply on the
web UI. I haven't really thought it through fully, but this _should_ do
most of what you're looking for, right?

Stephen

> 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.
> 
> Stephen
> 
> [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.
> 
> _______________________________________________
> Patchwork mailing list
> Patchwork@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/patchwork