-fixes and ff-only

[Daniel Vetter]

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.
>
> 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