[Kde-pim] Problems with infrastructure

[Jan Kundrát]

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/