[Kde-pim] Problems with infrastructure
Albert Astals Cid
aacid at kde.org
Wed Dec 10 18:41:31 GMT 2014
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
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
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.
> With kind regards,
More information about the kde-core-devel