-fixes and ff-only

Jani Nikula jani.nikula at linux.intel.com
Mon Apr 30 09:39:22 UTC 2018


Late to the party...

On Wed, 25 Apr 2018, 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?

How important is it for you that drm-misc-fixes is up-to-date with the
latest -rc? If we miss an -rc, we'll just wait for the next opportunity
for the fast-forward rebase, and we don't do backmerges in the mean
time.

For us, pushing everything to drm-intel-next-queued and maintainers
cherry-picking to drm-intel-fixes or drm-intel-next-fixes is a mixed
blessing. On the one hand, it ensures dinq has all the fixes, and future
kernels won't miss a fix because of a conflict with features. We can
always resolve merge conflicts to dinq side and know it's the right
thing. On the other hand, the current -rc kernel may suffer from this if
the cherry-pick doesn't apply; the fix stays in dinq until next merge
window. And then there's the dupe commits from cherry-picks that I kind
of expect someone to start raging about at some point.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center


More information about the dim-tools mailing list