Late to the party... On Wed, 25 Apr 2018, Sean Paul <seanp...@google.com> wrote: > Hey maintainers, > I'm noticing a trend which is unlikely to slow down, so I'd like to get > your input. I send my -fixes (and other) pull requests typically on > Wednesday afternoons (ET) to allow Dave plenty of time to pick them up and > send them to Linus. > > Unfortunately this means that if anything applied to -fixes between the > pull being sent and me getting into work on Monday morning (after the > latest rc is cut) will result in a backmerge instead of a fast forward. In > previous releases, volume was low enough that I won the race most weeks. > However, now that we have (many) more contributors, I almost always expect > to lose. > > So, what do? Intel has a drm-intel-next-queued where they manually sort and > apply their patches to the various trees. This allows them to wait for the > next rc before piling on any more fixes. I don't expect this will work for > -misc since it likely requires more time and collaboration than we have to > give. > > We could create a drm-misc-fixes-queued branch and leave drm-misc-fixes to > be manually curated by the maintainer handling the current release. Of > course, that same person would need to ensure that drm-misc-fixes-queued is > maintained as well (does intel just regularly backmerge to dinq > regularly?). Are there any other options we're missing?
How important is it for you that drm-misc-fixes is up-to-date with the latest -rc? If we miss an -rc, we'll just wait for the next opportunity for the fast-forward rebase, and we don't do backmerges in the mean time. For us, pushing everything to drm-intel-next-queued and maintainers cherry-picking to drm-intel-fixes or drm-intel-next-fixes is a mixed blessing. On the one hand, it ensures dinq has all the fixes, and future kernels won't miss a fix because of a conflict with features. We can always resolve merge conflicts to dinq side and know it's the right thing. On the other hand, the current -rc kernel may suffer from this if the cherry-pick doesn't apply; the fix stays in dinq until next merge window. And then there's the dupe commits from cherry-picks that I kind of expect someone to start raging about at some point. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ dim-tools mailing list dim-tools@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dim-tools
