Mark McLoughlin <mar...@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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
