On Wed, Apr 25, 2018 at 7:00 PM, Sean Paul <[email protected]> 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?
Adding Dave, since in the end he's got to look cute&cuddly when Linus starts rampaging. On the problem itself: No idea how to fix it. The issue with a drm-misc-fixes-queued is that eventually you have to rebase it, and rebasing a shared tree is not really cool (patches will get lost sooner or later). Backmerging -next trees is a lot less of an issue I think since Linus just plain doesn't look at the huge pulls we're sending him. As long as there's not too many merges in there (and seriously some subsystems do merges per individual patch, so we're far away from anything that looks funny). But with -fixes he's probably looking at stuff more because less pull request flood. Since -fixes-queued still requires rebased, what if we just try to at least rebase every 2nd week or so (instead of backmerging all the time), and see how that works? Rebase ofc needs to be really, really careful and make sure that upstream hasn't moved while we've rebased. Could/should probably script that. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dim-tools mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dim-tools
