linux-kernel - Re: [GIT PULL] tracing: Updates for v6.9

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]

Date: Sat, 16 Mar 2024 11:42:42 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Masami Hiramatsu <mhiramat@...nel.org>, 
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Beau Belgrave <beaub@...ux.microsoft.com>, 
	Chengming Zhou <zhouchengming@...edance.com>, Huang Yiwei <quic_hyiwei@...cinc.com>, 
	John Garry <john.g.garry@...cle.com>, Randy Dunlap <rdunlap@...radead.org>, 
	Thorsten Blum <thorsten.blum@...lux.com>, Vincent Donnefort <vdonnefort@...gle.com>, 
	linke li <lilinke99@...com>, Daniel Bristot de Oliveira <bristot@...hat.com>
Subject: Re: [GIT PULL] tracing: Updates for v6.9

On Sat, 16 Mar 2024 at 11:20, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> 1) Rebase without them (I know how much you love rebasing)

This.

Except honestly, the pulls are getting to be so complicated for me
because I have to check them, that I'd really like you to start doing
topic branches for individual things.

That's what we ended up doing with the security layers too, because
there were too many cases of "that is broken, I can't pull it", and
then having one single branch for everything meant that it was always
a "all or nothing" thing.

The security layer issues have largely gone away, but I still pull
things individually, and I think it actually ended up working out
well. Yes, I see more pulls, but not only are they clearer for me, the
code history ends up being much clearer too.

So topic branches tend to make for more actual pull requests, but when
the individual pulls are smaller and have clear "this branch does XYZ
and nothing more", it turns out that the actual effort per pull ends
up being less, and it actually clarifies things a lot too.

In fact, the x86 -tip people ended up doing topic branches just to
make things easier to review, rather than any "I can't pull that"
issues, and I think it actually ended up being something that they
preferred to do anyway.

Now, I'm not suggesting anything like the multiple topic branches from
-tip (from a quick check, there's been a total of 25 tip/tip topic
branches merged just this merge window), but for clear new features
definitely.

And no cross-merges between those topic branches, because that defeats
the whole purpose.

Do you have to do it for the current situation where I just can't take
the mmap stuff? No. But please look at it going forward.

           Linus