-fixes and ff-only

[Rodrigo Vivi]

On Wed, Apr 25, 2018 at 05:00:56PM +0000, Sean Paul 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?

We don't do that regularly, but only on need basis. For instance when there was
some define coming from drm-misc that is already on drm-next that we need
to continue to develop on i915.

People maintaining the -queued and -fixes are different. Our rotation is on
the target version.
For instance Jani is maintaining the drm-intel-next-queued targeting it for 4.18
While Joonas is maintaining drm-intel-fixes for 4.17

On next round:
I will take drm-intel-next-queued and drm-intel-next-fixes for 4.19
Jani will then take the drm-intel-fixes for 4.18.

Rotation is one version from begin to end.

I believe this could work on drm-misc as well. Another advantage of the manual
cherry picking for fixes is that most of developers don't need to worry about
conflict fixing.

Thanks,
Rodrigo.

> 
> Sean
> _______________________________________________
> dim-tools mailing list
> dim-tools at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dim-tools