-fixes and ff-only

[Sean Paul]

On Wed, Apr 25, 2018 at 2:10 PM Daniel Vetter <daniel at ffwll.ch> wrote:

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

Yeah, I was thinking -fixes would be the queue and there would be a
-fixes-for-dave or somesuch. Anyways, this will at least solve my problem,
and avoid having my name on all of the ugly backmerges going to Linus ;-).

So, unless anyone objects, I'll rebase -fixes before sending Dave my PR in
an hour or so.

Sean


> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch