Re: [GIT PULL] bcachefs fixes for 6.12-rc2

[Kent Overstreet]

On Sat, Oct 05, 2024 at 03:34:56PM GMT, Linus Torvalds wrote:
> On Sat, 5 Oct 2024 at 11:35, Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote:
> >
> > Several more filesystems repaired, thank you to the users who have been
> > providing testing. The snapshots + unlinked fixes on top of this are
> > posted here:
> 
> I'm getting really fed up here Kent.
> 
> These have commit times from last night. Which makes me wonder how
> much testing they got.

The /commit/ dates are from last night, because I polish up commit
messages and reorder until the last might (I always push smaller fixes
up front and fixes that are likely to need rework to the back).

The vast majority of those fixes are all ~2 weeks old.

> And before you start whining - again - about how you are fixing bugs,
> let me remind you about the build failures you had on big-endian
> machines because your patches had gotten ZERO testing outside your
> tree.

No, there simply aren't that many people running big endian. I have
users building and running my trees on a daily basis. If I push
something broken before I go to bed I have bug reports waiting for me
_the next morning_ when I wake up.

> That was just last week, and I'm getting the strong feeling that
> absolutely nothing was learnt from the experience.
> 
> I have pulled this, but I searched for a couple of the commit messages
> on the lists, and found *nothing* (ok, I found your pull request,
> which obviously mentioned the first line of the commit messages).
> 
> I'm seriously thinking about just stopping pulling from you, because I
> simply don't see you improving on your model. If you want to have an
> experimental tree, you can damn well have one outside the mainline
> kernel. I've told you before, and nothing seems to really make you
> understand.

At this point, it's honestly debatable whether the experimental label
should apply. I'm getting bug reports that talk about production use and
working on metadata dumps where the superblock indicates the filesystem
has been in continuous use for years.

And many, many people talking about how even at this relatively early
point it doesn't fall over like btrfs does.

Let that sink in.

Btrfs has been mainline for years, and it still craps out on people. I
was just in a meeting two days ago, closing funding, and a big reason it
was an easy sell was because they have to run btrfs in _read only_ mode
because otherwise it craps out.

So if the existing process, the existing way of doing things, hasn't
been able to get btrfs to a point where people can rely on it after 10
years - perhaps you and the community don't know quite as much as you
think you do about the realities of what it takes to ship a working
filesystem.

And from where I sit, on the bcachefs side of things, things are going
smoothly and quickly. Bug reports are diminishing in frequency and
severity, even as userbase is going up; distros are picking it up (just
not Debian and Fedora); the timeline I laid out at LSF is still looking
reasonable.

> I was hoping and expecting that bcachefs being mainlined would
> actually help development.  It has not. You're still basically the
> only developer, there's no real sign that that will change, and you
> seem to feel like sending me untested stuff that nobody else has ever
> seen the day before the next rc release is just fine.

I've got a team lined up, just secured funding to start paying them and
it looks like I'm about to secure more.

And the community is growing, I'm reviewing and taking patches from more
people, and regularly mentoring them on the codebase.

And on top of all that, you shouting about "process" rings pretty hollow
when I _remember_ the days when you guys were rewriting core mm code in
rc kernels.

Given where bcachefs is at in the lifecycle of a big codebase being
stabilized, you should be expecting to see stuff like that here. Stuff
is getting found and fixed, and then we ship those fixes so we can find
the next stuff.

> You're a smart person. I feel like I've given you enough hints. Why
> don't you sit back and think about it, and let's make it clear: you
> have exactly two choices here:
> 
>  (a) play better with others
> 
>  (b) take your toy and go home

You've certainly yelled a lot...