-fixes and ff-only

Daniel Vetter daniel at ffwll.ch
Wed Apr 25 18:10:46 UTC 2018


On Wed, Apr 25, 2018 at 8:07 PM, Sean Paul <seanpaul at chromium.org> wrote:
> On Wed, Apr 25, 2018 at 1:56 PM Daniel Vetter <daniel at ffwll.ch> wrote:
>
>> Works better with an untypoed airlied.
>
>> On Wed, Apr 25, 2018 at 7:55 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
>> > On Wed, Apr 25, 2018 at 7:00 PM, Sean Paul <seanpaul at 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?
>> >
>> > 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.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


More information about the dim-tools mailing list