Works better with an untypoed airlied. On Wed, Apr 25, 2018 at 7:55 PM, Daniel Vetter <[email protected]> wrote: > 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
-- 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
