Problems with infrastructure

Christian Mollekopf chrigi_1 at
Fri Dec 12 08:35:52 GMT 2014

On Wednesday 10 December 2014 16.53:09 Jan Kundrát wrote:
> 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 :).

I do like being able to view patches individually, so that's fine by me. I 
just want to avoid sending and reviewing individual patches when they belong 

The current workflow I'm using for reviewing is that I review feature branches 
developed by others, and if I'm happy with them I merge them and delete them 
from upstream.

What I lack with that is of course a tool to communicate about defects in the 
provided patches. Reviewboard can be used for that, but creating a reviewboard 
entry for every commit is IMO too much work, and having all commits merged 
isn't all that useful as it get's messy.

So if gerrit allows to treat feature branches as a whole while not merging the 
commits it may just be what I need.

> 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.
Thanks for the offer. Right now I lack the time for this experiment, but I'll 
get back to you when I see an opportunity.

KDE PIM mailing list kde-pim at
KDE PIM home page at

More information about the kde-core-devel mailing list