openstack team mailing list archive

[Mark McLoughlin <markmc@xxxxxxxxxx>]

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.

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.

The problem is we're pushing the responsibility for resolving merge
conflicts back on the author of the original commit. This creates a
pretty crazy scenario where folks are racing each other to get merged
and the loser gets to rebase again, and maybe again and again.

With subsystem branches, we're making a tiny step away from that. Either
the subsystem maintainer or main branch maintainer will need to resolve
the conflicts since the subsystem branch can't just be rebased.

So, I'd like to see:

  - Subsystem maintainer proposes a tree for merging into master.

    (How can we make this proposal appear in the maintainers queue as a
    single "merge this" work item?)

  - A main branch maintainer (the PTL?), reviews the proposal, pulls
    the commit into his master branch in his local repo (i.e. creates a
    new merge commit) and resolves any conflicts

  - Main branch maintainer pushes this to Jenkins for gating and final 
    merging into master (unless another commit gets merged in the 
    meantime, this will be a fast-forward merge)

In the longer term, I'd think I'd like to see gating work more like
this:

  - Developers submit patches to gerrit for review

  - Jenkins picks these patches up and runs the gating tests on them

  - When the code has been acked by reviewers and Jenkins, it goes into 
    the maintainer's merge queue

  - The maintainer merges stuff in batches from his queue in gerrit into
    his local repo, resolving conflicts etc.

  - The maintainer pushes the resulting tree to a private repo somewhere

  - Jenkins picks up the tree, runs the gating tests and fast-forward 
    merges it into master

There's a whole bunch of positives to that scheme:

  - Less frustrating pushback on developers when there are merge 
    conflicts, removing that scaling limitation

  - There's less of a rush by folks to get stuff merged, because merge 
    conflicts don't cause such a merry-go-round of rebasing

  - It fits with what we need for the subsystem branch scheme

  - The PTL gets to cast his eye over everything, allowing him to more 
    easily flame people if a patch wasn't adequately reviewed

  - The PTL has a lot more discretion to e.g. merge a security patch 
    quickly

  - The PTL's batches serve as better synchronization points, so the 
    history looks cleaner

And for completeness, a variant of the scheme above would be where the
maintainer may cherry-pick/rebase commits (rather than merge them) with
some exceptions like subsystem merge props or long patch series. This
would be a massive improvement in the cleanliness of our history and is
exactly analogous to what the kernel maintainers do when applying
patches submitted to a mailing list.

Cheers,
Mark.