Open Stack

Mark McLoughlin <markmc at redhat.com> writes:

> Hey,
>
> So, one thing came really stuck out to me when comparing our process to
> the kernel process:
>
>   In the kernel process, maintainers are responsible for running 
>   'git-merge' and they see it as their job to resolve conflicts.
>
>   In our process, Jenkins runs 'git-merge' and runs away screaming at 
>   the first sign of conflict.

Gerrit is what is responsible for merging commits, not Jenkins.  Jenkins
is listed as the author of some merge commits because it has instructed
Gerrit to merge those changes.

Gerrit fast-forwards branches when it is able, and automatically merges
when it is unable to fast-forward.  Every merge commit you see in the
history that is made by Jenkins represents a rebase that _did not_ have
to be done by a human.  As you may have noted, it's quite a lot
actually.  Ultimately, I think it represents a large savings in human
work.

> The kernel developers I talked to see this as the biggest hindrance to
> scaling and are fairly incredulous we've managed to scale this far with
> it.

I might agree with them if I had only read your description above.

Keep in mind that the Kernel has something like six times the rate of
change and number of contributors as all of OpenStack.  The Android Open
Source Project also uses Gerrit and it too is quite a bit larger than we
are.

Vish, Thierry, and I spent some time together this week at UDS trying to
reconcile their needs and your suggestions.  I believe Thierry is going
to write that up and send it to the list soon.

-Jim