Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 11 Aug 2023 12:54:42 +0200
From:   Christian Brauner <brauner@kernel.org>
To:     Kent Overstreet <kent.overstreet@linux.dev>,
        Linus Torvalds <torvalds@linux-foundation.org>
Cc:     linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
        linux-bcachefs@vger.kernel.org, djwong@kernel.org,
        dchinner@redhat.com, sandeen@redhat.com, willy@infradead.org,
        josef@toxicpanda.com, tytso@mit.edu, bfoster@redhat.com,
        jack@suse.cz, andreas.gruenbacher@gmail.com, peterz@infradead.org,
        akpm@linux-foundation.org, dhowells@redhat.com, snitzer@kernel.org,
        axboe@kernel.dk
Subject: Re: [GIT PULL] bcachefs
Message-ID: <20230811-neigt-baufinanzierung-4c9521b036c6@brauner>
References: <20230626214656.hcp4puionmtoloat@moria.home.lan>
 <20230706155602.mnhsylo3pnief2of@moria.home.lan>
 <20230712025459.dbzcjtkb4zem4pdn@moria.home.lan>
 <CAHk-=whaFz0uyBB79qcEh-7q=wUOAbGHaMPofJfxGqguiKzFyQ@mail.gmail.com>
 <20230810155453.6xz2k7f632jypqyz@moria.home.lan>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20230810155453.6xz2k7f632jypqyz@moria.home.lan>
Precedence: bulk

> I don't want to do that to Christian either, I think highly of the work
> he's been doing and I don't want to be adding to his frustration. So I
> apologize for loosing my cool earlier; a lot of that was frustration
> from other threads spilling over.
> 
> But: if he's going to be raising objections, I need to know what his
> concerns are if we're going to get anywhere. Raising objections without
> saying what the concerns are shuts down discussion; I don't think it's
> unreasonable to ask people not to do that, and to try and stay focused
> on the code.

The technical aspects were made clear off-list and I believe multiple
times on-list by now. Any VFS and block related patches are to be
reviewed and accepted before bcachefs gets merged.

This was also clarified off-list before the pull request was sent. Yet,
it was sent anyway.

On the receiving end this feels disrespectful. To other maintainers this
implies you only accept Linus verdict and expect him to ignore
objections of other maintainers and pull it all in. That would've caused
massive amounts of frustration and conflict should that have happened.
So this whole pull request had massive potential to divide the
community. And in the end you were told the same requirements that we
did have and then you accepted it but that cannot be the only barrier
that you accept.

And it's not just all about code. Especially from a maintainer's
perspective. There's two lengthy mails from Darrick and from you with
detailed excursions about social aspects as well.

Social aspects in fact often come into the center whenever we focus on
code. There will be changes that a sub-maintainer may think are
absolutely required and that infrastructure maintainers will reject for
reasons that the sub-maintainer might fundamentally disagree with and we
need to be confident that a maintainer can handle this gracefully and
respectfully. If there's strong indication to the contrary it's a
problem that can't be ignored.

To address this issue I did request at LSFMM that I want a co-maintainer
for bcachefs that can act as a counterweight and balancing factor. Not
just a reviewer but someone who is designated in making decisions in
addition to you and can step in. That would be may preferred thing.

Timeline wise, my preference would be if we could get the time to finish
the super work that Christoph and Jan are currently doing and have a
cycle to see how badly the world breaks. And then we aim to merge
bcachefs for v6.7 in November. That's really not far away and also gives
everyone the time to calm down a little.