[Kde-pim] Problems with infrastructure

[Albert Astals Cid]

El Dimecres, 10 de desembre de 2014, a les 16:53:09, Jan Kundrát va escriure:
> On Wednesday, 10 December 2014 10:28:59 CEST, Christian Mollekopf wrote:
> > * pull requests/the webinterface: reviewboard is awesome for single
> > patches
> > every now and then, it's rather useless when you work with
> > branches IMO. With github we have a nice webinterface to review
> > branches while keeping it simple.
> > Gerrit may be what I'm looking for though (never used it,
> > looking forward to see how the testing goes).
> 
> That depends on what you're looking for. Gerrit puts emphasis on review of
> individual patches. It will present related patches "together", but you
> won't be able to review them as a single entity -- the goal of Gerrit is to
> ensure that the history is clean, and it is operating under an assumption
> that each commit matters. Unless I'm mistaken, a GitHub pull request shows
> you a diff which represents the starting point and the final point of that
> branch as a single unit, with an option to go into individual commits.
> Gerrit is different -- not worse, different :).
> 
> Regarding the "testing of Gerrit", I haven't received much feedback yet.
> Three repositories are using it so far (kio, plasma-framework, trojita),
> and if a repo owner/maintainer of some other project is willing to take
> part in this testing, I won't see a problem with it.

I see some problems with gerrit:

 A) it makes our messaging more complex, we tell people to use reviewboard, 
except for these 3 repos, which you have to use a different tool

 B) As a "gardener" it makes my life harder, now I have to go through two 
different patch tracking systems and see if people forgot to commit or review 
stuff in two different systems.

 C) In case I was a developer of some of those projects it would it harder for 
me to also check what's the status of my patches since i would need to visit 
two webs instead of one.

 D) There's no way to create a review without using relatively unfriendly 
gerrit process

A, B, and C are solved if gerrit is only in testing to eventually replace 
reviewboard totally; but not if it is meant to coexist with reviewboard (which 
would make some people happier but would in my opinion be negative for the 
common good).

D is really important to me since it makes it harder to contribute to non 
hardcore git users; it took me days to start understanding Qt's gerrit and i 
am still not sure i understand it fully, with reviewboard i do git diff and 
use the web to upload a patch, as simple as it gets.

And yes, i know people complain about reviewboard, but that is because it's 
the tool we use, if we used gerrit, we would probably get complains too. I 
want to make sure we're not investing time in what at the end is most probably 
a zero sum height.

Cheers,
  Albert

> 
> With kind regards,
> Jan