Message-ID: <4l32ehljkxjavy3d2lwegx3adec25apko3v355tnlnxhrs43r4@efhplbikcoqs>
Date: Thu, 18 Jul 2024 18:24:08 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Linus Torvalds <torvalds@...ux-foundation.org>
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, Jul 18, 2024 at 03:06:07PM GMT, Linus Torvalds wrote:
> 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:

Sorry, I must not have been clear. My master branch is a) not where I do
development, and b) not not a branch that I will be sending to you -
that's simply the primary branch I publish for people testing the latest
bcachefs code.

So: master will now be just updated by a hook on the server whenever I
update for-next.

> 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.

Yes, this will help with that; last cycle I had to rebase at rc4 because
of something my testers were hitting, but it wasn't affecting my
development so with the new setup my development branches will be able
to stay based on rc1.

> > 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.

Oh?

Does it now?

I've gotten essentially zero in the way of test feedback from for-next
(except from Stephen Rothwell directly, the odd build warning or merge
issue, but 0day mostly catches the build stuff before it hits next).

And I don't think the rest of the filesystem community is any different,
because a major subject at LSF this year was in fact the need for
someone to start a fs-next branch for 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.

Yes, that's exactly what I was describing.
> 
> 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.

Ditto

> 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),

No, the integration branch isn't for testing other code, it's because
they don't want to be running rc1 if rc4 or rc7 is out.

That's literally all it is.

Powered by blists - more mailing lists