[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7dwjsfnrxyxewrxsyznkl6kbgilnfisom7igpeyesmihktejqt@njz4xjtpcgw5>
Date: Sat, 24 Aug 2024 07:48:28 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: "Carl E. Thompson" <list-bcachefs@...lthompson.net>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] bcachefs fixes for 6.11-rc5
On Fri, Aug 23, 2024 at 09:22:55PM GMT, Carl E. Thompson wrote:
> Kent, I'm not a kernel developer I'm just a user that is impressed with bcachefs, uses it on his personal systems, and eagerly waits for new features. I am one of the users who's been using bcachefs for years and has never lost any data using it.
>
> However I am going to be blunt: as someone who designs and builds Linux-based storage servers (well, I used to) as part of their job I would never, ever consider using bcachefs professionally as it is now and the way it appears to be developed currently. It is simply too much changed too fast without any separation between what is currently stable and working for customers and new development. Your work is excellent but **process** is equally and sometimes even more important. Some of the other hats I've worn professionally include as a lead C/C++ developer and as a product release manager so I've learned from very painful experience that large projects absolutely **must** have strict rules for process. I'm sure you realize that. Linus is not being a jerk about this. Just a couple of months ago Linus had to tell you the exact same thing he's telling you again here. And that wasn't the first time. Is your plan to just continue to break the rules and do whatever the heck you want until
You guys are freaked out because I'm moving quickly and you don't have
visibility into my own internal process, that's all.
I've got a test clusture, a community testing my code before I send it
to Linus, and a codebase that I own and know like the back of my hand
that's stuffed with assertions. And, the changes in question are
algorithmically fairly simple and things that I have excellent test
coverage for. These are all factors that let me say, with confidence,
that there really aren't any bugs in this this pull request.
Look, there will always be a natural tension between "strict rules and
processes" vs. "weighing the situations and using your judgement". There
isn't a right or wrong answer as to where on the spectrum we should be,
we just all have to use our brains.
No one is being jerks here, Linus and I are just sitting in different
places with different perspectives. He has a resonsibility as someone
managing a huge project to enforce rules as he sees best, while I have a
responsibility to support users with working code, and to do that to the
best of my abilities.
Powered by blists - more mailing lists