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