Re: RFE: use patchwork to submit a patch

[Greg KH <gregkh@linuxfoundation.org>]

On Thu, Oct 10, 2019 at 10:41:50AM -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/
> 
> How I envision this would work:
> 
> - user creates an account (which requires a mail confirmation)
> - they choose a "submit patch" option from the menu
> - the patch submission screen has a succession of screens:
> 
>  1. a screen with a single field allowing a user to paste a URL to     their
> fork of the git repository. Once submitted, patchwork does a     "git
> ls-remote" to attempt to get a list of refs and to verify that     this is
> indeed a valid git repository

s/valid git repository/valid git repository based on the kernel git tree/

Otherwise you might be sending out lots of emails for other projects :)

> 
>  2. next screen asks the user to select the ref to work from using the
> list obtained from the remote. Once submitted, patchwork performs a     `git
> clone --reference` to clone the repository locally using a     local fork of
> the same repo to minimize object transfer. This part     requires that:
>       a. patchwork project is configured with a path to a local fork,
> if this feature is enabled for a project
>       b. that fork is kept current via some mechanism outside of
> patchwork (e.g. with grokmirror)
>       c. there is some sanity-checking during the clone process to
> avoid abuse (e.g. a sane timeout, a tmpdir with limited size,          etc
> -- other suggestions welcome)
> 
>  3. next screen asks the user to pick a starting commit from the log.
> Once submitted, patchwork generates the patch from the commit     provided
> to the tip of the branch selected by the user earlier,
>     using git format-patch.
> 
>  4. next screen asks the user to review the patch to make sure this is
> what they want to submit. Once confirmed, patchwork performs two
> admin-defined optional hooks:
> 
>       a. a hook to generate a list of cc's (e.g. get_maintainer.pl)
>       b. a sanity check hook (e.g. checkpatch.pl)

I will note that many "first patch" submissions are checkpatch.pl
cleanups for staging.  When doing that, I require that they do "one
logical change per patch", which means that many of the individual
patches themselves will not be checkpatch.pl clean, because many lines
have multiple issues with them (tabs, spaces, format, length, etc.)

So other than that minor thing, sounds interesting.  It's hard to
determine just how difficult the whole "set up git and send a patch out"
process is for people these days given the _huge_ numbers of new
contributions we keep getting, and the numerous good tutorials we have
created that spell out exactly how to do this.

So you might be "solving" a problem that we don't really have.  It's
hard to tell :(

> I know this is a pretty big RFE, and I would like to hear your thoughts
> about this. If there is general agreement that this is doable/good idea, I
> may be able to come up with funding for this development as part of the
> overall tooling improvement proposal.

The workflow seems sane, and matches what most people do today, with the
exception that it "solves" the git send-email issue, right?  Is that our
biggest barrier?

I would recommend interviewing some of the recent kernel mentor project
and outreachy applicants first, to try to determine exactly what their
problems, if any, were with our development process.  If they say that
this type of tool/workflow would have saved them hours of time and
energy, then that's a great indication that we should try to do this.

thanks,

greg k-h