On Thursday, 11 December 2014 00:51:28 CEST, Albert Astals Cid wrote:
Yes, it is harder.
Yyou need to setup git correctly, so that "gerrit" in that
command is valid,
you need to understand you're pushing to a different server than the "real"
one, you need to commit (i never do format-patch, just git
diff), all in all
needs you go have a bigger git-understanding.
I see what you're saying, and you're probably right -- there's a bar,
indeed. That bar could however be effectively removed by having a
spoonfeeding, step-by-step documentation on how to submit patches with
Gerrit. I'm still hoping that I'm not the only guy who cares about this,
and that maybe someone else is going to produce such a howto (hint for
bystanders: now is the time, I've put quite a few hours into this already).
Furthermore, there are upstream patches under review for making it possible
to create a review through the web, with no use of CLI tools or a `git
push` equivalent of any sort. When these are released, I'll be happy to
upgrade, as usual.
Besides in reviewboard i could get a tarball, produce a diff and upload it
easily, i have not investigated Luigi's links yet, but "as far
as i know" that
is not easy/doable in gerrit.
Do we have some stats saying how many people download tarballs / zips from
ReviewBoard? Is there a User-Agent breakdown for the patch submission to RB
so that we could look on how many people do push files around, and can we
compare that to the number of people using rb-tools? I'll be happy to do
the number crunching myself, but I don't have access to the logs.
Anyway, I understand that my experience is probably going to differ from
the experience of anybody else to some extent, but to me, the hardest thing
in making a patch is usually finding out what changes to make in a random
C++ file of a project whose sources I'm seeing for the first time. Compared
to *that*, creating a git diff has always been much easier for me.
Moreover, when that patch is ready, someone still need to commit it and
make sure that it doesn't introduce any regressions. Right now, all parts
of this duty are effectively up to the project maintainer, which means that
the process doesn't scale at all. Unless the patch author is a KDE
developer already (in which case I fully expect them to be able to
copy-paste three commands from a manual to be able to push to Gerrit), a
project maintainer has to fetch stuff from RB by hand, copy-paste a commit
message, perform a build cycle, verify that stuff still works and upload
the result to git.
Considering a typical turnover time of patches which I see within KDE, I
don't think that we have superfluous reviewers or project maintainers, so
my suggestion is to prioritize making their workflow easier at the expense
of, well, forcing the contributors to spend their time copy-pasting a
couple of commands from a manual *once* during the course of their
involvement with a given project.
Anyway, I know that pre-Gerrit proccess was so painful for me that I
actually decided to invest dozens of hours of my time into this, and get
the Gerrit + CI ball rolling, and I'm not really willing to go back into
shuffling bits around by hand. This is 2014, and we have computers to do
repeated bits for us, don't we?
I've had my fair share of beers tonight, so I hope I won't manage to offend
people by my blutness here.
Cheers,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
