archive mirror
 help / color / mirror / Atom feed
From: Daniel Vetter <>
To: Stephen Rothwell <>
Cc: intel-gfx <>,
	dri-devel <>,
	Dave Airlie <>,
	linux-next <>
Subject: Re: linus-next: update to the drm-intel-fixes tree
Date: Wed, 4 Sep 2013 11:05:55 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Stephen

On Wed, Sep 4, 2013 at 1:45 AM, Stephen Rothwell <> 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?

Thanks, Daniel
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 -

  reply	other threads:[~2013-09-04  9:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-03 23:45 linus-next: update to the drm-intel-fixes tree Stephen Rothwell
2013-09-04  9:05 ` Daniel Vetter [this message]
2013-09-05 12:57   ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).