Group maintainership models
Group maintainership models
Posted Nov 3, 2016 12:46 UTC (Thu) by jani (subscriber, #74547)Parent article: Group maintainership models
The part that we're having issues with is the fixes workflow. We apply everything to our -next branch, and cherry-pick the fixes to a branch queued to -rc kernels. When the -next branch gets merged upstream in the merge window, the same commits sit both sides of the merge. Git doesn't handle that well, and I guess it's not unfair to call that "nasty". The workflow is not unlike the stable kernel workflow, with the important difference that stable doesn't get merged back upstream, so there are no conflicts.
The one thing I haven't seen a good answer to is this: If there's a non-rebasing -next tree, and we find out that there's a fix in there that fixes an issue in Linus' tree, what's the proper way to get that fix to -rc kernels? If you've already pushed the fix to a non-rebasing tree that can't be merged to -rc kernels, you can't merge your way out of this until the next merge window. This problem is independent of the maintainer model. We've just chosen to queue all the fixes to -next and cherry-pick from there (I can elaborate the reasons later if there's interest), but the problem doesn't go away completely by using topic branches, let alone by changing the maintainer model.
Posted Nov 3, 2016 14:21 UTC (Thu)
by dtor (subscriber, #39360)
[Link] (1 responses)
Posted Nov 3, 2016 16:12 UTC (Thu)
by jani (subscriber, #74547)
[Link]
This assumes we always know in advance which patches we want to, and, not insifigantly, are confident to queue to -rc. Basically the decision would have to be made at the time the patch is applied. This is what we did before, with at least the following problems:
1) We would fail to identify a fix, queuing to -next instead, and being at the same situation as we are currently: either cherry-picking from branch to another, or moving from branch to another by way of rebasing.
2) We would queue a fix to -rc, only to find out a bit later that it breaks things. With the cherry-pick model, we can choose the good fixes after they've seen more testing in our -next. (This could be mitigated by moving some of our QA/CI resources from our -next to -rc, but ideally we should focus on getting our -next properly tested.)
3) With the decision of which branch to push to being so important, we often ended up in indecision and stalling while trying to always make the right decision. In the end, we'd often err on the safe side, leading to 1).
4) With our developers and QA and CI working on -next, we'd typically write the fixes on -next first, only to figure out later that the fix does not apply to -rc. We'd stall figuring out what the fix for -rc is, leaving the bug unfixed in both. Getting this right would require knowing where to push the patch before writing the patch...
5) With the fixes in -rc, and -next moving rapidly, we'd sometimes have difficult conflicts around the fixes. Now, we can always resolve to the version in our -next and be sure it contains all the fixes.
I'm sure we could find ways to mitigate all of these. It's just that as a driver, i915 really is *very* actively developed by a large crowd. See git shortlog -sn on drivers/gpu/drm/i915 and contrast with pretty much any directory under drivers, or almost any top level directory. Our workflow of pushing everything to -next first has really worked well for us except for the problems caused by cherry-picks in git merges.
Group maintainership models
Group maintainership models
> your -next, resolving conflicts as needed? That will make sure git recognizes then
> add same commits.