Re: [Libreoffice] breathing master

On Sun, May 22, 2011 at 10:35 AM, Bjoern Michaelsen
<bjoern.michaelsen@canonical.com> wrote:
> On Sun, 22 May 2011 17:00:19 +0200
>
> Just as a sidenote: gerrit looks awesome and we should try it before
> testing Reviewboard. I wonder though, given its tight git integration,
> if we should really try a setup before onegit is around.

Agreed, on both point.

I installed it locally and played a bit with it. it _is_ awesome.
and I haven't played yet with another great stuff command line tools:
http://gerrit.googlecode.com/svn/documentation/2.1.7/cmd-index.html

That should make writting glue and helper script fairly easy, to
automate tings and integrate it with other tools...
or even for power-user that find web-based tools too cumbersome or too slow.

The notion of mutlple review indeed is possible. a reviewer can tag a
review as 'ok but need more review' or 'ok it's good'
so on a 3-review-needed branch, the reviewer can look at the history
of reviews and if he is the third one then say 'it's good'
otherwise 'ok but need more review'

Another great feature is that you can essentially checkout a version
with change pending review 'applied' to do a verification (build, test
etc)
in a git like-fashion (the client side thinks it is talking to a real
git repo and therefore get stuff with git fetch/pull as usual)
before the change is actually committed to the 'real' git.
The web interface even give you, for each change under review, the git
command to do that (either by checkout, pull or cherry-pick or even
how to extract it as a patch)

Once approved and verified a set of commit can be 'published' that is
to the local git underlying gerrit. it is also possible to push stuff
to a remote git
All of these action are controlled via a fairly flexible access control scheme.

There are multiple options to control how a change get applied
(fast-forward, merge, cherry-pick) and gerrit detect conflict. in case
of conflcit one can re-submit a modified change, that will be tracked
a next version of the same change (using a Change-Id that is managed
by a git hook to uniquely identify a change).

Gerrit seems to be able to track dependencies between changes under
review (stuff like 'this patch depend on this patch'). I haven't
investigated yet how that work.

Now, on with the 'beware' stuff:

1/ to do review and most other thing a simple web access to the gerrit
web server is enough, BUT in order to actually push a change into the
system for review, one need to have a git+ssh setup, need to
understand git push and how it works, and need to learn the specific
trick to push for-review change in gerrit.
It is not _that_ complicated, but it not adequate for an occasional
patch or for someone very green with git and dev in general.
In other word, we would need to : a/ provide a proper ./git/config
wired to gerrit and probably some git-alias to ease the common
manipulation b/ have some serious documentation, with example and all,
about the desired workflow c/ possibly a sandbox so that people can
verify what they learned without much consequences.

2/ gerrit is not meant to scrub mailing list, so in itself it would
not solve that problem. but, it seems fairly doable to write a script
to do that. to make such scrip reliable it is probably needed to a/
have a dedicated ML to submit patch to gerrit and b/ have a little
script on the client to wrap around git-send-email to do sanity check
and add metadata (like the branch for witch this patch is intended).
In any case, even without any of this, the job of scrubbing manually
the ML for patches become easier, because the person that do that just
need to apply the patch and push it to gerrit for review. iow the
burden or reviewing/testing the patch does not necessarily fall on the
poor soul that scrub the ML.

3/ gerrit use a database as back-end. the gerrit project recommend to
use the built-in H2 database, but Postgress and MySQL are also
supported. From an operational point of view, some thought needs to be
given to backup and fail-over for that system (gerrit web service +
database + underlying git) which could have an influence on the choice
of database back-end.

Conclusion:
Gerrit is a really neat tool, I was swept away :-)

Norbert