Received-SPF: pass (google.com: domain of linux-kernel+bounces-105293-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Sat, 16 Mar 2024 22:07:12 +0100
From: Borislav Petkov <bp@alien8.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Beau Belgrave <beaub@linux.microsoft.com>,
	Chengming Zhou <zhouchengming@bytedance.com>,
	Huang Yiwei <quic_hyiwei@quicinc.com>,
	John Garry <john.g.garry@oracle.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Thorsten Blum <thorsten.blum@toblux.com>,
	Vincent Donnefort <vdonnefort@google.com>,
	linke li <lilinke99@qq.com>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	x86-ml <x86@kernel.org>
Subject: Re: [GIT PULL] tracing: Updates for v6.9
Message-ID: <20240316210712.GEZfYKADWKOdILezL3@fat_crate.local>
References: <20240315122934.1d3231ce@gandalf.local.home>
 <CAHk-=wg24KPFfeNwYdsD0e79MP4QhO3VaWkh0buPSD0M=141xQ@mail.gmail.com>
 <CAHk-=wh5wWeib7+kVHpBVtUn7kx7GGadWqb5mW5FYTdewEfL=w@mail.gmail.com>
 <20240316142002.7480d74b@rorschach.local.home>
 <CAHk-=wgKJti5WBi7VmA_ETDiXjmkEqvVW7De5ajwtkyJ=c==kA@mail.gmail.com>
 <20240316200015.GAZfX6T9ftKSv0-Zs5@fat_crate.local>
 <CAHk-=wiGymybvnQu2=+nzc18HkRudoeJODci13RBDr5afyDjfg@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAHk-=wiGymybvnQu2=+nzc18HkRudoeJODci13RBDr5afyDjfg@mail.gmail.com>

On Sat, Mar 16, 2024 at 01:42:06PM -0700, Linus Torvalds wrote:
> But if it's a "one pull to fix a single-line issue in resource
> control, and another pull to fix a single-line issue in objtool", then
> those make perfect sense to keep separate, even if they are both
> trivial and small.

Yeah, that's what they are - we do topic branches so it is always
separate topics - just sometimes they don't have too much going on
during a particular cycle.

Ok, understood - separate pulls, even if small ones, are fine.

> And on the other hand, if you have a couple of trivial branches with
> no real pattern, and decide to just merge them into one that fixes
> "misc x86 problems", and the end result is still completely trivial
> and there are no surprises or gotchas, that's not wrong either.

Ack.

> And sometimes, merging and sending me just one pull request is
> absolutely the right thing.
> 
> For example, the ARM SoC trees tend to just merge "umbrella" updates
> into one single pull request, and I prefer that - because I see no
> point in getting ten different "this is the drivers for SoC xyz"
> thing.

Right.

I do a similar thing with the EDAC tree because it is all EDAC - no need
for separate pulls. We just keep them separate in case we have to rebase
early in the game to keep history clean. Yeah, well, rebase only if it
would get relatively ugly if not.

And then Tony or I merge them all into a single pull.

> So then it's still a clear topic branch ("ARM SoC drivers"), but they
> kept multiple branches for different SoC's and sent me just one pull
> request.
> 
> End result: there's no one right thing.  Make it make sense. Probably
> the only real rule is
> 
>  - try to keep conceptually different things separate just for cleanliness
> 
>  - definitely keep fundamental new features or anything that _might_
> be questionable in a branch of its own

Ok, understood. Makes sense.

> but there aren't some kind of black-and-white rules for "this is so
> small that it's not worth sending on its own".
> 
> This merge window, I think I currently have something like ~15 merges
> that ended up being literally just a couple of lines (maybe spread
> over two or three files). I don't mind at all. If that's all that
> happened, that's fine.

.. and that is also some sort of documenting it: this area didn't see
that much development this cycle.

Thanks for explaining.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette