Different Gerrit workflows -- was Master branch now requires liborcus 0.5.0 or higher.

On Tue Apr 16 09:32:13 PDT 2013, Kohei Yoshida wrote: 

> > On Sat, Apr 13, 2013 at 5:55 AM, Bjoern Michaelsen <
> > bjoern.michaelsen at canonical.com> wrote:

> > BTW, this seems like a prime example benefitting from "upload to
gerrit,
> > let
> > someone schudule a test build on all platforms" -- any reason you
skipped
> > that?

> Skipped?  I don't use gerrit for things that need to be done right
> away. So it wasn't even an option.  I needed that to be done right away
> so that I could move on to doing other things which depended on it.
> Putting that up on gerrit and wait for a few days or more was never an
> option for this.
> Plus, the whole feature branch needed to be merged, which isn't a
> typical
> use case for gerrit review system anyway.

I feel like there is a lot of misunderstanding here.

LO's Gerrit site installation doesn't enforce code review and patch
verification, permitting all commiters to push directly to master,
bypassing Gerrit review & verification facility completely.
But you can still benefit from Gerrit buildbot verification facility
only.

What can tb/tinbuild2 - Gerrit-buildbot tool chain do for you today?
* it builds your single Gerrit patch/Gerrit branch/serie of Gerrit
patches on three different platforms: Linux 64bit, Mac OS X 32bit,
Windows 32bit, MSVS 2008.

What can it do for you in (near) future?
* we are going to put more hardware on it
* add (optionally) further platforms (mingw, iOS, Android, ...),
architectures (Linux 32 bit, Mac OS X 64 bit), compilers (clang, MSVS
2010, 2012, ...), configurations (--with-foo, --without-bar), ...

Different Gerrit wokflows
=========================

a. upload a single patch to Gerrit and let it test build on buildbot
(discouraged, see b.). Submit it to master if it was successful or amend
and repeat.

Note: If you think you are wasting ca. 2 hours (time currently needed
for Windows build, that we hopefully can improve), then you are just
wrong. You saved a lot of frustration of other devs by not breaking
master.

b. upload the content of local branch to Gerrit's review, so called
series of patches: p_1 ... p_n and let it test build on buildbot. Again,
submit it to master if it was successful or amend and repeat. 

In fact Gerrit is currently missing native support for series of patches
(they call it Gerrit topic review feature [1]) as the first class
objects. With such support it should be possible to submit, abandon or
let verify all changes that belong to the topic as single entity. The
guys from kitware patched their Gerrit and enabled it [2], check the two
top level entities in their Gerrit UI: topic & changes). One reason they
did it is not having enough hardware on all different platforms to check
every patch isolated, it resembles me that we suffer from the same
problem ;-) Gerrit core developers are going to discuss about the ways
to upstream that feature to Gerrit on upcoming spring Hackathon [3].

So back to your use case: the content of your feature branch can be put
on Gerrit for *only* verification (not wasting days or weeks but only 2
hours) with *one* command:
git push logerrit <your_branch>:refs/for/master
(or even put your whole branch on gerrit for review/verification, like
libreoffice-4) and let test build it and push if it was OK, or amend and
repeat.

Sure, you must not do it (not yet ;-), but then consider to make all
those cross platform checks for current and future platforms,
architectures, compilers and configurations that buildbot offer to you
for granted on your own site to make sure you don't break master.

[1] https://groups.google.com/forum/#!
msg/repo-discuss/gXjbuhfW0tg/21ORzuycLoIJ
[2] http://review.source.kitware.com/#/q/entity:topic%20status:open,n,z
[3] http://gerritforge.com/gerrit-london-hackathon.html 

David