-fixes and ff-only

[Sean Paul]

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?

Sean

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