[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKMK7uHn_qFrfK9Dkd41NdXd-VHFsbH4gdnX3+J=0GQ_H0C0Mw@mail.gmail.com>
Date: Wed, 28 Apr 2021 20:14:31 +0200
From: Daniel Vetter <daniel.vetter@...ll.ch>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Dave Airlie <airlied@...il.com>,
dri-devel <dri-devel@...ts.freedesktop.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] drm for 5.13-rc1
On Wed, Apr 28, 2021 at 7:07 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Tue, Apr 27, 2021 at 8:32 PM Dave Airlie <airlied@...il.com> wrote:
> >
> > There aren't a massive amount of conflicts, only with vmwgfx when I
> > did a test merge into your master yesterday, I think you should be
> > able to handle them yourself, but let me know if you want me to push a
> > merged tree somewhere (or if I missed something).
>
> The conflict was easy enough to resolve, but was unusual in that my
> tree had vmwgfx fixes that weren't in the development tree (ie that
> commit 2ef4fb92363c: "drm/vmwgfx: Make sure bo's are unpinned before
> putting them back").
>
> Usually when I merge stuff, I can see that the fixes that were pushed
> to my tree are also in the development branch. Not so this time.
Maybe we're overdoing it a bit, but we're trying to not backmerge all
the time for no reason at all. Only when someone requests it due to
more more patches for the dev tree that need both stuff from -fixes
and -next. Also keeps you entertained during the merge window :-) Plus
I think it keeps us more honest with really just pushing minimal
bugfixes to -fixes to keep conflicts reasonable and all that.
But if it's a bit overdone I guess we can backmerge a bit more often.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Powered by blists - more mailing lists