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