cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hugo Trippaers <>
Subject Re: [DISCUSS] Introducing Gerrit for quality? was: [PROPOSAL] Using continuous integration to maintain our code quality...
Date Tue, 10 Jun 2014 06:22:35 GMT

I’m all for automated solutions. I’m a happy gerrit user on some other projects and quite
fond of working with Github pull requests as well. However there is one important point that
makes working with those tools work and that is a willingness by the committers to review
requests. Both systems rely on either a well functioning and fast CI system or committers
that consistently and rapidly review requests. Where the latter is actually the most important

Both gerrit and pull requests do not improve quality. They are just tools to facilitate a
certain way of working. If we want to improve quality we have to do it ourselves, no amount
of automated tooling is going to solve it for us. As committers it is our job to review commits
and make sure that quality is maintained. It is also our job to make sure that automated tests
exist that will catch problems.

At the moment we have a 433,412 line codebase with on average 3.91 potential defects per line
of code (according to coverity). We have a very small amount of unit test coverage on our
core code and no real idea how much or what code is covered by functional testing. If we want
to improve quality i think that is the place to start. 

Of course it is also wise to see if we can improve the quality of the incoming commits, but
that is easily done by taking a few moments during the day to review everything that was pushed
to master and fix, revert and add unit tests where required. Coach committers/contributors
that consistently have trouble with adding testing cases on how to do it. That part is the
responsibility of being a committer, not just the bit that allows access to the repo.

If we are able to get this bit going, i’ll happily jump on any barricade and start a revolution
to get whatever automated tooling we need to support this process.



On 10 jun. 2014, at 06:15, Rajani Karuturi <> wrote:

> +1 for github pull requests. They are much better and cleaner than review board.
> ~Rajani
> On 09-Jun-2014, at 9:17 pm, David Nalley <<>>
> On Fri, Jun 6, 2014 at 7:26 PM, Sheng Yang <<>>
> Hi all,
> Seems it's a good timing to bring back the discussion about the gerrit.
> We want to do CI, and improve our code quality. One obvious way of doing
> and reduce the workload of devs is introduce a tool to enforce the process.
> I've checked out quite a few projects using gerrit, which would force you
> to ask for review, and validation before the code can be committed to the
> repo. Looks it's really a easier way for devs according what I've heard.
> Even our competitor laid out a very detail workflow based on the use of
> gerrit( ). I guess it can
> make a good reference.
> Well, gerrit has been brought up a few times before. And now the new
> process we want to enforce just fits what gerrit(or other automation
> review/test/commit software) is for.
> Maybe it's the time for us to review the possibility of using a tool to
> enforce our commits and improve our code quality(as well as transfer
> knowledge) again?
> --Sheng
> ASF Infra has a very dour view on Gerrit. Don't read that as
> impossible; there are many projects at the ASF who are interested in
> Gerrit.
> That said; what about moving to using github pull requests instead of
> RB, and from their, having the jenkins pull request builder
> automatically process every pull request and list information.
> Here's an example:
> You'll see that every time the patch changes, the jenkins plugin
> pulled the patch - ran tests against it and reported back.
> That said; it almost seems like we have the cart before the horse; we
> need to finish figuring out the CI Infrastructure first.
> --David

View raw message