From: Daniel Vetter <firstname.lastname@example.org>
To: Stephen Rothwell <email@example.com>
Cc: intel-gfx <firstname.lastname@example.org>,
Dave Airlie <email@example.com>,
Subject: Re: linus-next: update to the drm-intel-fixes tree
Date: Thu, 5 Sep 2013 14:57:48 +0200 [thread overview]
Message-ID: <20130905125748.GG27291@phenom.ffwll.local> (raw)
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 <firstname.lastname@example.org> 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
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
prev parent reply other threads:[~2013-09-05 12:57 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
2013-09-05 12:57 ` Daniel Vetter [this message]
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 \
* 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).