From: Dave Airlie <airlied@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
LKML <linux-kernel@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [git pull] drm for 6.1-rc1
Date: Thu, 6 Oct 2022 06:56:08 +1000 [thread overview]
Message-ID: <CAPM=9tx+qa5aucS7Sa4Lg4SAD7PamCYsPwSupgd1xix1Y9HEkg@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wgJmLVs7MYd=uF4+b32Fwmvgc0MLr4TEUSBEPf5U6=W5g@mail.gmail.com>
On Thu, 6 Oct 2022 at 04:38, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Tue, Oct 4, 2022 at 8:42 PM Dave Airlie <airlied@gmail.com> wrote:
> >
> > This is very conflict heavy, mostly the correct answer is picking
> > the version from drm-next.
>
> Ugh, yes, that was a bit annoying.
>
> I get the same end result as you did, but I do wonder if the drm
> people should try to keep some kind of separate "fixes" branches for
> things that go both into the development tree and then get sent to me
> for fixes pulls?
>
> Hopefully this "lots of pointless noise" was a one-off, but it might
> be due to how you guys work..
In this case I think it was a late set of fixes backported for new AMD
hardware, that had to be redone to fit into the current kernel that
caused most of it. I haven't seen it this bad in a long while. We also
maintain a rerere tree ourselves to avoid continuously seeing it.
The problem is a lot of developers don't have the insight that the
maintainers do into the current state of the tree/pipeline.
Stuff goes into next because that is where the patch it fixes
originally went, and it goes through CI there. Then at some point
someone else realises the change needs to be in fixes and it gets
backported.
The volume of patches and company signoff processes doesn't make it
trivial to upfront decide what needs to go in -next or -fixes
unfortunately.
Dave.
next prev parent reply other threads:[~2022-10-05 20:56 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-05 3:41 [git pull] drm for 6.1-rc1 Dave Airlie
2022-10-05 18:38 ` Linus Torvalds
2022-10-05 20:56 ` Dave Airlie [this message]
2022-10-05 18:40 ` pr-tracker-bot
2022-10-06 18:47 ` Linus Torvalds
2022-10-06 19:28 ` Alex Deucher
2022-10-06 19:47 ` Linus Torvalds
2022-10-06 20:14 ` Alex Deucher
2022-10-06 20:24 ` Dave Airlie
2022-10-06 21:41 ` Dave Airlie
2022-10-06 21:52 ` Dave Airlie
2022-10-06 23:45 ` Linus Torvalds
2022-10-07 2:45 ` Dave Airlie
2022-10-07 2:54 ` Dave Airlie
2022-10-07 3:03 ` Dave Airlie
2022-10-07 6:11 ` Christian König
2022-10-07 8:16 ` Daniel Vetter
2022-10-07 9:28 ` Daniel Vetter
2022-10-06 19:29 ` Dave Airlie
2022-10-06 19:41 ` Linus Torvalds
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPM=9tx+qa5aucS7Sa4Lg4SAD7PamCYsPwSupgd1xix1Y9HEkg@mail.gmail.com' \
--to=airlied@gmail.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).