-fixes and ff-only

[Gustavo Padovan]

On Wed, 2018-04-25 at 18:19 +0000, Sean Paul wrote:
> 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.c
> > > > > om>
> 
> 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.

I'm fine with experimenting with -fixes rebases every two weeks or so.
For me you can go ahead with it.

Gustavo

-- 
Gustavo Padovan
Principal Software Engineer
Collabora Ltd.