On Wed, Sep 04, 2013 at 11:05:55AM +0200, Daniel Vetter wrote:

Hi Stephen

On Wed, Sep 4, 2013 at 1:45 AM, Stephen Rothwell sfr@canb.auug.org.au Wrote:

...

This morning after fetching the drm-intel-fixes tree, I have discovered that you have just added a whole set of patches on top of Dave's drm tree and made that the drm-intel-fixes tree. I understood that this tree was for fixes to Linus' tree for the current release cycle. Given that Dave's tree has not been merged by Linus (yet), this is a bit inconsistent. Not only that, but now if I merge your tree early (which is what I do with the -fixes trees), I will also merge all of Dave's tree. That in turn would mean that I would have missed the (what would have been automatically applied) merge for I am carrying for Dave's tree. :-(

I am going to have to drop your -fixes tree for today.

If these are fixes for stuff in Linus' tree, then they should have been based on Linus' tree - if they are fixes for Dave's tree, then they should have been in your drm-intel tree, right?

(fetches more trees ...) And now, I discover that they are the latter :-)

So your -fixes tree will be dropped, but all those patches will still be merged via you drm-intel tree.

Hm, my workflow is to keep my feature queue branch open even through the merge window. To avoid pains I have the special for-linux-next tree which should only ever point at patches relevent for the current release cycle.

Now when the upstream merge window opens I take that patch queue and split out all the features that haven't made it into drm-next in time so that I'm left with only the bugfixes. That I then push to my -fixes branch. Then I rebase my feature queue on top of that.

So essentially as soon as the merge window upons my -fixes branch is for the current release and based on top of drm-next. And if there's any leftover fixes I just rebase them, too. While the merge window is open for-linux-next also points at the -fixes branch (but will switch back to the feature queue once -rc1 is out).

I guess to make you happy I could create a for-linux-next-fixes branch which would only be used in the -rc phase to include my -fixes into linux-next. I don't want to delay the -fixes split until drm-next is merged upstream since that usually happens rather late in the merge window. Would that work for you?

Ok I've implemented this and added a new for-linux-next-fixes branch which should only contain drm/i915 -fixes that apply on top of linus git and nothing from Dave's drm tree. Please yell if this branch contains stuff you don't want to see there. Atm it's just v3.11 since all the stuff on tops of Dave's drm-next is in for-linux-next (and drm-next also isn't yet merged).

Thanks, Daniel