-fixes and ff-only

[Sean Paul]

On Mon, Apr 30, 2018 at 12:39:22PM +0300, Jani Nikula wrote:
> 
> Late to the party...

I have been on vacation since Thursday, so this is good timing for me :-)

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

Yeah, perhaps this release cycle has been worse than others, but this week is
rc4 and there's already a fix queued. If we didn't rebase or backmerge, we would
still be based on rc1. The policy was working pretty well, but now that we have
more committers, it's going to become less likely that we'll win the race
between PR send and rc cut. 

We could possibly delay sending the fixes PRs to reduce the window, but that
reduces the amount of time Dave has to pull everything together.

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

I don't think a -fixes-queued branch would suffer from that since it would
just be for fixes, and they would not be applied to -misc-next (as is the
situation today). That said, I doubt rebasing -misc-fixes every 2 weeks is
causing too much heartburn, so it seems like a good middle road until
someone complains.

I'll keep checking every Monday to see if I can ff -fixes, but I think we should
have some [in]formal process in case it drifts too far off.

Sean

> 
> BR,
> Jani.
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

-- 
Sean Paul, Software Engineer, Google / Chromium OS