linux-kernel - Re: [git pull] drm for 6.17-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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAHk-=whCQ5fYwt0X3mzD8zXK=pzWNYeFEUX=H6n4TWdjkOXbDw@mail.gmail.com>
Date: Wed, 30 Jul 2025 20:49:11 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Dave Airlie <airlied@...il.com>
Cc: Simona Vetter <simona@...ll.ch>, dri-devel <dri-devel@...ts.freedesktop.org>, 
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] drm for 6.17-rc1

On Wed, 30 Jul 2025 at 20:39, Dave Airlie <airlied@...il.com> wrote:
> >
> > But I do think that the drm people are doing actively wrong things
> > with the random cherry-picks back and forth: they cause these
> > conflicts, and I *really* think you should look at maybe using stable
> > fixes branches instead.
> >
> > Would that require more care and cleaner trees? Yes. And that's kind
> > of the point. You are being messy, and it's affecting the quality of
> > the end result.
>
> I'm not sure how to parse, stable fixes branch, do you mean stable as
> in a special branch for stable tree? or a fixes tree we don't rebase
> every rc?

I mean as in "don't cherry-pick fixes between trees".

Create a separate fixes branch that is *stable* and that is *shared*
between the trees.\

> Currently all the base (drm, intel, xe, amdgpu) fixes branches are
> stable, we backmerge into them after rc1, and very occasionally
> afterwards if a backmerge from rc5/6 is needed.

Not at all.

What you do ihas absolutely *nothing* to do with stable fixes branches.

You do random development in the main branch, and then when you make a
fix, you just do that in the main branch, and do a cherry-pick into
some other random branch.

Search for "cherry picked from commit" in your logs. There were *92*
duplicate patches that were randomly cherry-picked from on ebranch to
another.

That is *NOT* a "shared fixes branch". That's just throwing patches aroung.

And that is literally what is causing all the conflicts - you have
those duplicate commits in multiple branches, and then you do other
random development around them.

> We should only cherry-pick one direction,

That's nonsensical. There is no such thing as "cherry-pick one direction".

Direction doesn't matter at all. A cherry-pick is a cherry-pick.

It doesn't make one whit of difference whether you cherry-pick
backwards or forwards, rightside up or upside down, or while sitting
in a tree singing the national anthem.

The end result is the exact same thing. You have two different commits
in two different branches, and then you have unrelated changes around
them in those branches.

               Linus