-fixes and ff-only

[Daniel Vetter]

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