From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Cc: patchwork@lists.ozlabs.org, workflows@vger.kernel.org
Subject: Re: RFE: use patchwork to submit a patch
Date: Thu, 10 Oct 2019 15:53:35 -0400 [thread overview]
Message-ID: <20191010195335.fmh6atylozhehftt@chatter.i7.local> (raw)
In-Reply-To: <20191010150729.1355f33d@coco.lan>
On Thu, Oct 10, 2019 at 03:07:29PM -0300, Mauro Carvalho Chehab wrote:
>> - 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.
>
>This will raise the bar, as it will force all developers to have a
>public site to host the tree. I guess only a fraction of the 4k kernel
>devs have it... In special, the ones that just want to send us a patch
>fixing a bug may have serious troubles implementing that.
I don't think this will raise the bar, as Github/Gitlab allow for very
easy forking of https://github.com/torvalds/linux. This is also not at
all aimed at "all developers" -- only those that don't want to use the
current CLI workflow and are more comfortable with web tools like
Github.
>> 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)
>
>That would require a high bandwidth at the machine with as patchwork.
>Also, doesn't sound a good idea to me, as the server may end by having
>tons of open sections, most waiting for tens of minutes, in order to
>complete git clone.
This is actually really fast if you already have a local copy of the
repository with most objects. Try this yourself if you have
torvalds/linux.git locally:
git clone --bare -s torvalds/linux.git test
cd test
git remote add arm-soc https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git fetch arm-soc for-next
The whole process takes a second or so and the resulting repo is 328K in
size.
Of course, this assumes that the remote repository isn't trying to do
something nasty, which is why I suggest anti-abuse precautions.
>> 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 procedure itself is not bad, but, if implemented, IMHO, it should,
>instead, be something that will run at the machine of the one submitting
>the patch. For instance, this could be a perl or python script inside
>Kernel's ./script directory that would handle everything locally, and
>then submit the patch via patchwork's REST API.
I think I didn't make clear that this isn't supposed to go straight to
patchwork. Patchwork is merely a convenient tool where this happens --
the resulting patch gets mailed out to the mailing list just as the user
would have done.
-K
next prev parent reply other threads:[~2019-10-10 19:53 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-10 14:41 RFE: use patchwork to submit a patch Konstantin Ryabitsev
2019-10-10 18:07 ` Mauro Carvalho Chehab
2019-10-10 19:42 ` Steven Rostedt
2019-10-10 19:53 ` Konstantin Ryabitsev [this message]
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=20191010195335.fmh6atylozhehftt@chatter.i7.local \
--to=konstantin@linuxfoundation.org \
--cc=mchehab+samsung@kernel.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).