linux-kernel - Re: [GIT PULL] bcachefs changes for 6.11

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-=wgzMxdCRi9Fqhq2Si+HzyKgWEvMupq=Q-QRQ1xgD_7n=Q@mail.gmail.com>
Date: Thu, 18 Jul 2024 15:06:07 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: Waiman Long <longman@...hat.com>, linux-bcachefs@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] bcachefs changes for 6.11

On Thu, 18 Jul 2024 at 14:21, Kent Overstreet <kent.overstreet@...ux.dev> wrote:
>
> But my master branch (previously the same as for-next) will now be
> for-next merged with the latest tag from your tree, and I may do
> similarly for bcachefs-for-upstream if it's needed.

No. No back-merges. We actually have documentation about this, so I
won't repeat the hundreds of emails I've sent out:

  Documentation/maintainer/rebasing-and-merging.rst

But the gist of it (well, one of them) is that you should keep your
branch *YOUR* branch, not think that you should merge in other peoples
work into it (or rebase it on top of random work by other developers).

There are valid reasons to rebase, but they are balanced against some
VERY valid reasons not to do it, so if you have to rebase, make sure
those reasons really outweigh the reasons not to.

And don't do it just before a pull request - and if there is some
catastrophic event that caused a recent rebase, let me know in the
pull request.

> As a bonus, this means the testing automation will now be automatically
> testing my branch + your latest

No. That's what linux-next is about - it does integration testing.

Your development branch IS NOT FOR TESTING OTHER RANDOM THINGS.

You are actively making things worse if you do: you should worry about
YOUR code, not about all the random other things going on.

Now, if you want to do _additional_ testing along the lines of "what
happens with my branch and Linus' latest" then that is ok - but that
should be something you see as completely separate from testing your
own work.

IOW, you can certainly wear "multiple hats" - your bcachefs developer
hat that worries about your bcachefs branch, and if you want to *also*
do some integration testing, go right ahead and have another
"integration testing branch" that you then test separately.

But I don't want your integration path. When I get a bcachefs pull, I
want the *bcachefs* side to be solid and tested. Not something else.

So by all means keep multiple branches for different reasons. If you
think you have users that need to test some integration branch (which
honestly sounds like a horrible idea, but you do you), make them a
branch too if you really want to. But again, that has NOTHING to do
with bcachefs development, and you should not mix that up with what
you send me.

                  Linus