From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: patchwork@lists.ozlabs.org, workflows@vger.kernel.org
Subject: RFE: use patchwork to submit a patch
Date: Thu, 10 Oct 2019 10:41:50 -0400 [thread overview]
Message-ID: <20191010144150.hqiosvwolm3lmzp5@chatter.i7.local> (raw)
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
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)
5. if sanity checking is defined, next screen shows the output of the
sanity check hook, asking confirmation to proceed.
6. next screen shows the user three fields:
a. title of the patch/series
b. cover letter for the patch/series
c. message-id of the previous patch revision (can be picked from
the list of previously submitted series by this user --
patchwork should have them already)
d. number of the revision (can be auto-filled if previous field
is provided) and other tags to include in []
7. next screen shows final review of what would be sent out to the
list (and cc's, if the hook to get cc's is defined and returned any
results). Once submitted, patchwork sends the patch/series using
patchwork's envelope-from and the user's own email in the From:
header.
8. once sent successfully, cleanups are performed (also needs to be
done as part of the regular cron job, for any aborted attempts)
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.
Best regards,
-K
next reply other threads:[~2019-10-10 14:41 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-10 14:41 Konstantin Ryabitsev [this message]
2019-10-10 18:07 ` RFE: use patchwork to submit a patch Mauro Carvalho Chehab
2019-10-10 19:42 ` Steven Rostedt
2019-10-10 19:53 ` Konstantin Ryabitsev
2019-10-10 20:05 ` Eric Wong
2019-10-10 20:21 ` Jonathan Nieder
2019-10-10 20:36 ` Eric Wong
2019-10-11 18:05 ` Mauro Carvalho Chehab
2019-10-10 20:20 ` Jonathan Nieder
2019-10-10 21:38 ` Daniel Axtens
2019-10-10 22:05 ` Konstantin Ryabitsev
2019-10-11 8:57 ` Greg KH
2019-10-11 17:20 ` Shuah Khan
2019-10-11 17:37 ` Mauro Carvalho Chehab
2019-10-11 18:01 ` Steven Rostedt
2019-10-11 18:32 ` David Miller
2019-10-11 18:44 ` Steven Rostedt
2019-10-11 18:51 ` Mauro Carvalho Chehab
2019-10-11 18:59 ` Mauro Carvalho Chehab
2019-10-11 19:02 ` Drew DeVault
2019-10-11 19:11 ` David Miller
2019-10-11 21:19 ` Stephen Hemminger
2019-10-11 21:47 ` Steven Rostedt
2019-10-11 22:54 ` Dave Airlie
2019-10-11 23:00 ` Steven Rostedt
2019-10-12 0:08 ` Stephen Hemminger
2019-10-12 0:14 ` Steven Rostedt
2019-10-13 23:38 ` Daniel Axtens
2019-10-14 10:42 ` Toke Høiland-Jørgensen
2019-10-14 12:26 ` Theodore Y. Ts'o
2019-10-14 13:18 ` Toke Høiland-Jørgensen
2019-10-14 13:41 ` Mauro Carvalho Chehab
2019-10-14 13:53 ` Theodore Y. Ts'o
2019-10-14 14:28 ` Mauro Carvalho Chehab
2019-10-14 15:25 ` Konstantin Ryabitsev
2019-10-14 12:27 ` Daniel Axtens
2019-10-14 13:19 ` Steven Rostedt
2019-10-14 14:58 ` Dmitry Vyukov
2019-10-14 15:12 ` Laurent Pinchart
2019-10-15 4:49 ` Dmitry Vyukov
2019-10-15 16:30 ` Laurent Pinchart
2019-10-14 15:17 ` Greg KH
2019-10-14 15:27 ` Laurent Pinchart
2019-10-15 4:41 ` Dmitry Vyukov
2019-10-15 16:07 ` Greg KH
2019-10-14 20:56 ` Theodore Y. Ts'o
2019-10-15 4:39 ` Dmitry Vyukov
2019-10-15 12:37 ` Steven Rostedt
2019-10-15 13:35 ` Theodore Y. Ts'o
2019-10-15 14:05 ` Steven Rostedt
2019-10-15 15:21 ` Konstantin Ryabitsev
2019-10-15 16:37 ` Laurent Pinchart
2019-10-15 16:47 ` Steven Rostedt
2019-10-21 15:39 ` Laurent Pinchart
2019-10-24 13:15 ` Steven Rostedt
2019-10-24 13:33 ` Dmitry Vyukov
2019-10-24 13:58 ` Steven Rostedt
2019-10-24 14:12 ` Dmitry Vyukov
2019-10-15 8:57 ` Eric Wong
2019-10-15 9:11 ` Dmitry Vyukov
2019-10-15 16:24 ` Laurent Pinchart
2019-10-15 16:27 ` Laurent Pinchart
2019-10-21 11:16 ` Dmitry Vyukov
2019-11-08 9:44 ` Dmitry Vyukov
2019-11-08 14:02 ` Theodore Y. Ts'o
2019-11-08 14:11 ` Dmitry Vyukov
2019-11-08 14:12 ` Dmitry Vyukov
2019-11-08 14:17 ` Konstantin Ryabitsev
2019-11-08 14:25 ` Dmitry Vyukov
2019-11-09 4:31 ` Theodore Y. Ts'o
2019-11-11 9:35 ` Dmitry Vyukov
2019-11-11 12:08 ` Mark Brown
2019-11-11 16:17 ` Theodore Y. Ts'o
2019-11-11 20:38 ` Konstantin Ryabitsev
2019-11-08 14:17 ` Laurent Pinchart
2019-10-11 20:02 ` Konstantin Ryabitsev
2019-10-11 21:23 ` Eric Wong
2019-10-11 21:35 ` Konstantin Ryabitsev
2019-10-12 7:19 ` Greg KH
2019-10-14 11:31 ` Mark Brown
2019-10-15 16:11 ` Konstantin Ryabitsev
2019-10-13 23:39 ` Eric Wong
2019-10-14 7:30 ` Geert Uytterhoeven
2019-10-14 22:18 ` Eric Wong
2019-10-15 15:34 ` Konstantin Ryabitsev
2019-10-14 15:33 ` Laurent Pinchart
2019-10-15 15:40 ` Konstantin Ryabitsev
2019-10-15 16:32 ` Laurent Pinchart
2019-10-15 16:34 ` Drew DeVault
2019-10-15 16:44 ` Laurent Pinchart
2019-10-15 17:07 ` Drew DeVault
2019-10-15 17:24 ` Konstantin Ryabitsev
2019-10-11 22:57 ` Dave Airlie
2019-10-12 7:31 ` Greg KH
2019-10-12 13:16 ` Stephen Finucane
2019-10-12 16:13 ` Stephen Finucane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191010144150.hqiosvwolm3lmzp5@chatter.i7.local \
--to=konstantin@linuxfoundation.org \
--cc=patchwork@lists.ozlabs.org \
--cc=workflows@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).