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: <1816164937.417.1724473375169@mail.carlthompson.net>
Date: Fri, 23 Aug 2024 21:22:55 -0700 (PDT)
From: "Carl E. Thompson" <list-bcachefs@...lthompson.net>
To: Kent Overstreet <kent.overstreet@...ux.dev>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Cc: 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

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
  Linus stops bothering you? I don't think that's a good plan.


Since I'm already being blunt I'm going to be even more blunt: you have a serious problem working with others. In the past and in this thread I've read where you seem to imply that other kernel developers are gatekeeping and resist some of your ideas because you've created something that (in your opinion) is already better in some ways than some of things they've created. But from where I'm sitting the problems you've experienced are 90% because of **you**. You're an adult and you need to understand that about yourself so you can do something about it.


I get that I've way overstepped my bounds here. If the kernel developers wish to ban me from the kernel lists I understand.

Carl


> On 2024-08-23 7:59 PM PDT Kent Overstreet <kent.overstreet@...ux.dev> wrote:
> 
>  
> On Sat, Aug 24, 2024 at 10:40:33AM GMT, Linus Torvalds wrote:
> > On Sat, 24 Aug 2024 at 10:35, Linus Torvalds
> > <torvalds@...ux-foundation.org> wrote:
> > >
> > > What is to be gained by having release rules and a stable development
> > > environment? I wonder.
> > 
> > But seriously - thinking that "I changed a thousand lines, there's no
> > way that introduces new bugs" is the kind of thinking that I DO NOT
> > WANT TO HEAR from a maintainer.
> > 
> > What planet ARE you from? Stop being obtuse.
> 
> Heh.
> 
> No, I can't write 1000 lines of bug free code (I think when I was
> younger I pulled it off a few times...).
> 
> But I do have really good automated testing (I put everything through
> lockdep, kasan, ubsan, and other variants now), and a bunch of testers
> willing to run my git branches on their crazy (and huge) filesystems.
> 
> And enough experience to know when code is likely to be solid and when I
> should hold back on it.
> 
> Are you seeing a ton of crazy last minute fixes for regressions in my
> pull requests? No, there's a few fixes for recent regressions here and
> there, but nothing that would cause major regrets. The worst in terms of
> needing last minute fixes was the member info btree bitmap stuff, and
> the superblock downgrade section... but those we did legitimately need.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ