Re: [Libreoffice-qa] Gerrit auto-merge

On Mon, Jun 4, 2012 at 1:02 AM, David Tardon <dtardon@redhat.com> wrote:
> On Sat, Jun 02, 2012 at 10:51:25AM +0200, Bjoern Michaelsen wrote:
> > So -- people with commit rights are not the issue:
> > - can commit directly to master on their own responsibility
> >   (this should be discouraged, except for urgent buildbreaker fixes that save
> >    everyone pain)
>
> Do I see the beginning of some "CWS" process here? Anyway, if the
> objective is to avoid build problems, then I think it is completely
> misplaced, because:
>
> * no amount of reviewing is going to cover all the configurations people
>  build with
> * most of build problems are on Windows and MacOS X and we do not have
>  enough people there (c.f. the recent threads regarding testing of
>  feature/gbuild_*)

The idea is to test build _before_ landing on master

The advantage of gerrit is that a tibderbox can test individual
patches in an automated fashion and without the need for speed that
the current tinderboxes have.
Right now it is very important to have fast tinderboxes to turn things
around fast enough to that borkage do not stock pile (as it used to be
with windows)

But with gerrit the build-testing scales up nicely as the time to test
build a given patch is not critical anymore... so we can make
productive use of any kind of box big and small.
Sure at first we won't have enough of them to really test every
patches on every platforms... but it is a reachable goal.
Furthermore this kind of setup would allow for tests to be run, even
slow ones, since again the time to process a given patch is less
critical than with today's setup.
So there won't be the need for a tug of war between speed and completeness.

Of course all of that will not materialize magically just because we
tart using gerrit, but it is a step toward the _possibility_ of such
infrastructure

> I do not think it is a good idea to start to do that for master commits
> wholesale. We have hardly enough people to review fixes for stable
> branches.

a/ gerrit make it easier to do such review
b/ the habit of doing review is indeed not the easiest thing in the
world to instill in a project (open source or not), but it is a worthy
goal.
c/ the burden and responsibility of a review for master is much less
than that of a review for stable branch. This goes back to the
discussion of 'lock sane' vs 'I know it is working, I'll stake my name
on it'

Norbert