linux-kernel - Re: [git pull] drm for 6.1-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPM=9tx+qa5aucS7Sa4Lg4SAD7PamCYsPwSupgd1xix1Y9HEkg@mail.gmail.com>
Date:   Thu, 6 Oct 2022 06:56:08 +1000
From:   Dave Airlie <airlied@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Daniel Vetter <daniel.vetter@...ll.ch>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] drm for 6.1-rc1

On Thu, 6 Oct 2022 at 04:38, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Tue, Oct 4, 2022 at 8:42 PM Dave Airlie <airlied@...il.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.