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: <ZKjd7nQxvzRDA2tK@casper.infradead.org>
Date:   Sat, 8 Jul 2023 04:54:22 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     James Bottomley <James.Bottomley@...senpartnership.com>
Cc:     Kent Overstreet <kent.overstreet@...ux.dev>,
        Christian Brauner <brauner@...nel.org>,
        "Darrick J. Wong" <djwong@...nel.org>,
        Josef Bacik <josef@...icpanda.com>,
        torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-bcachefs@...r.kernel.org,
        dchinner@...hat.com, sandeen@...hat.com, tytso@....edu,
        bfoster@...hat.com, jack@...e.cz, andreas.gruenbacher@...il.com,
        peterz@...radead.org, akpm@...ux-foundation.org,
        dhowells@...hat.com
Subject: Re: [GIT PULL] bcachefs

On Fri, Jul 07, 2023 at 12:26:19PM -0400, James Bottomley wrote:
> On Fri, 2023-07-07 at 05:18 -0400, Kent Overstreet wrote:
> > Christain, the hostility I'm reading is in your steady passive
> > aggressive accusations, and your patronizing attitude. It's not
> > professional, and it's not called for.
> 
> Can you not see that saying this is a huge red flag?  With you every
> disagreement becomes, as Josef said, "a hill to die on" and you then
> feel entitled to indulge in ad hominem attacks, like this, or be
> dismissive or try to bury whoever raised the objection in technical
> minutiae in the hope you can demonstrate you have a better grasp of the
> details than they do and therefore their observation shouldn't count.
> 
> One of a maintainer's jobs is to nurture and build a community and
> that's especially important at the inclusion of a new feature.  What
> we've seen from you implies you'd build a community of little Kents
> (basically an echo chamber of people who agree with you) and use them
> as a platform to attack any area of the kernel you didn't agree with
> technically (which, apparently, would be most of block and vfs with a
> bit of mm thrown in), leading to huge divisions and infighting.  Anyone
> who had the slightest disagreement with you would be out and would
> likely behave in the same way you do now leading to internal community
> schisms and more fighting on the lists.
> 
> We've spent years trying to improve the lists and make the community
> welcoming.  However technically brilliant a new feature is, it can't
> come with this sort of potential for community and reputational damage.

I don't think the lists are any better, tbh.  Yes, the LF has done a great
job of telling people not to use "bad words" any more.  But people are
still arseholes to each other.  They're just more subtle about it now.
I'm not going to enumerate the ways because that's pointless.

Consider this thread from Kent's point of view.  He's worked for years
on bcachefs.  Now he's asking "What needs to happen to get this merged?"
And instead of getting a clear answer as to the technical pieces that
need to get fixed, various people are taking the opportunity to tell him
he's a Bad Person.  And when he reacts to that, this is taken as more
evidence that he's a Bad Person, rather than being a person who is in
a stressful situation (Limbo?  Purgatory?) who is perhaps not reacting
in the most constructive way.

I don't think Kent is particularly worse as a fellow developer than you
or I or Jens, Greg, Al, Darrick, Dave, Dave, Dave, Dave, Josef or Brian.
There are some social things which are a concern to me.  There's no
obvious #2 or #3 to step in if Kent does get hit by the proverbial bus,
but that's been discussed elsewhere in the thread.

Anyway, I'm in favour of bcachefs inclusion.  I think the remaining
problems can be worked out post-merge.  I don't see Kent doing a
drop-and-run on the codebase.  Maintaining this much code outside the
main kernel tree is hard.  One thing I particularly like about btrfs
compared to ntfs3 is that it doesn't use old legacy code like the buffer
heads, which means that it doesn't add to the technical debt.  From the
page cache point of view, it's fairly clean.  I wish it used iomap, but
iomap would need quite a lot of new features to accommodate everything
bcachefs wants to do.  Maybe iomap will grow those features over time.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ