On Wed, Apr 25, 2018 at 2:10 PM Daniel Vetter <[email protected]> wrote:
> On Wed, Apr 25, 2018 at 8:07 PM, Sean Paul <[email protected]> wrote: > > On Wed, Apr 25, 2018 at 1:56 PM Daniel Vetter <[email protected]> wrote: > > > >> 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. > >> > > > > > Hopefully we can get ahead of it before rampage territory! > > > >> > 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. > > > > Yeah, that's why I'm not too worried about -misc-next or -next-fixes. > > > >> > > >> > 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. > > > > We could presumably have the same dim function both ff -fixes and then > > rebase -fixes-queued, doing the requisite checks along the way. Presumably > > the drm-tip integration is cool with a rebase once in a while? How about > > rerere? > drm-tip is totally fine with constant rebasing. It's developers > concurrently pushing patches while rebasing creating a mess. But if we > go with rebasing anyway then I'd still suggest we just rebase -fixes > for now and see what happens. Retraining everyone to push patches to > -fixes-queued, just for an experiment, is going to be a lot of effort. Yeah, I was thinking -fixes would be the queue and there would be a -fixes-for-dave or somesuch. Anyways, this will at least solve my problem, and avoid having my name on all of the ugly backmerges going to Linus ;-). So, unless anyone objects, I'll rebase -fixes before sending Dave my PR in an hour or so. Sean > -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
