public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Bill O'Donnell <bodonnel@redhat.com>
Cc: "Darrick J. Wong" <djwong@kernel.org>,
	Christoph Hellwig <hch@infradead.org>,
	cem@kernel.org, stable@vger.kernel.org, jlayton@kernel.org,
	linux-xfs@vger.kernel.org, hch@lst.de
Subject: Re: [PATCHSET v2] xfs: proposed bug fixes for 6.13
Date: Thu, 5 Dec 2024 09:39:42 +0100	[thread overview]
Message-ID: <2024120533-dirtiness-streak-c69d@gregkh> (raw)
In-Reply-To: <Z1Fd-FVR84x3fLVd@redhat.com>

On Thu, Dec 05, 2024 at 02:02:00AM -0600, Bill O'Donnell wrote:
> On Thu, Dec 05, 2024 at 01:46:58AM -0600, Bill O'Donnell wrote:
> > On Wed, Dec 04, 2024 at 11:33:21PM -0800, Darrick J. Wong wrote:
> > > On Thu, Dec 05, 2024 at 01:04:21AM -0600, Bill O'Donnell wrote:
> > > > On Wed, Dec 04, 2024 at 10:58:33PM -0800, Christoph Hellwig wrote:
> > > > > On Thu, Dec 05, 2024 at 12:52:25AM -0600, Bill O'Donnell wrote:
> > > > > > > 1) Our vaunted^Wshitty review process didn't catch various coding bugs,
> > > > > > > and testing didn't trip over them until I started (ab)using precommit
> > > > > > > hooks for spot checking of inode/dquot/buffer log items.
> > > > > > 
> > > > > > You give little time for the review process.
> > > 
> > > Seriously?!
> > > 
> > > Metadir has been out for review in some form or another since January
> > > 2019[1].  If five years and eleven months is not sufficient for you to
> > > review a patchset or even to make enough noise that I'm aware that
> > > you're even reading my code, then I don't want you ever to touch any of
> > > my patchsets ever again.
> > > 
> > > > > I don't really think that is true.  But if you feel you need more time
> > > > > please clearly ask for it.  I've done that in the past and most of the
> > > > > time the relevant people acted on it (not always).
> > > > > 
> > > > > > > 2) Most of the metadir/rtgroups fixes are for things that hch reworked
> > > > > > > towards the end of the six years the patchset has been under
> > > > > > > development, and that introduced bugs.  Did it make things easier for a
> > > > > > > second person to understand?  Yes.
> > > > > > 
> > > > > > No.
> > > > > 
> > > > > So you speak for other people here?
> > > > 
> > > > No. I speak for myself. A lowly downstream developer.
> > > > 
> > > > > 
> > > > > > I call bullshit. You guys are fast and loose with your patches. Giving
> > > > > > little time for review and soaking.
> > > > > 
> > > > > I'm not sure who "you" is, but please say what is going wrong and what
> > > > > you'd like to do better.
> > > > 
> > > > You and Darrick. Can I be much clearer?
> > > > 
> > > > > 
> > > > > > > > becoming rather dodgy these days. Do things need to be this
> > > > > > > > complicated?
> > > > > > > 
> > > > > > > Yeah, they do.  We left behind the kindly old world where people didn't
> > > > > > > feed computers fuzzed datafiles and nobody got fired for a computer
> > > > > > > crashing periodically.  Nowadays it seems that everything has to be
> > > > > > > bulletproofed AND fast. :(
> > > > > > 
> > > > > > Cop-out answer.
> > > > > 
> > > > > What Darrick wrote feels a little snarky, but he has a very valid
> > > > > point.  A lot of recent bug fixes come from better test coverage, where
> > > > > better test coverage is mostly two new fuzzers hitting things, or
> > > > > people using existing code for different things that weren't tested
> > > > > much before.  And Darrick is single handedly responsible for a large
> > > > > part of the better test coverage, both due to fuzzing and specific
> > > > > xfstests.  As someone who's done a fair amount of new development
> > > > > recently I'm extremely glad about all this extra coverage.
> > > > > 
> > > > I think you are killing xfs with your fast and loose patches.
> > > 
> > > Go work on the maintenance mode filesystems like JFS then.  Shaggy would
> > > probably love it if someone took on some of that.
> > 
> > No idea who "Shaggy" is. Nor do I care.	   
> > > 
> > > > Downstreamers like me are having to clean up the mess you make of
> > > > things.
> > > 
> > > What are you doing downstream these days, exactly?  You don't
> > > participate in the LTS process at all, and your employer boasts about
> > > ignoring that community process.  If your employer chooses to perform
> > > independent forklift upgrades of the XFS codebase in its product every
> > > three months and you don't like that, take it up with them, not
> > > upstream.
> 
> Why are you such a nasty person? I try to get along with people, but you're
> impossible. I've been an engineer for 40+ years, and I've never encountered such
> an arrogant one as you.

I have to step in here, sorry.

Please take a beat and relax and maybe get some sleep before you respond
again.  Darrick is not being "nasty" here at all, but reiterating the
fact that your company does do huge fork-lifts of code into their kernel
tree.  If that development model doesn't work for you, please work with
your company to change it.

And if you wish to help out here, please do so by reviewing and even
better yet, testing, the proposed changes.  If you can't just suck down
a patch series and put it into your test framework with a few
keystrokes, perhaps that needs to be worked on to make it simpler to do
from your side (i.e. that's what most of us do here with our development
systems.)

By critisizing the mere posting of bugfixes, you aren't helping anything
out at all, sorry.  Bugfixes are good, I don't know why you don't want
even more, that means that people are testing and finding issues to fix!
Surely you don't want the people finding the issues to be your users,
right?

thanks,

greg k-h

  reply	other threads:[~2024-12-05  8:39 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-04  3:02 [PATCHSET v2] xfs: proposed bug fixes for 6.13 Darrick J. Wong
2024-12-04  3:02 ` [PATCH 1/6] xfs: don't move nondir/nonreg temporary repair files to the metadir namespace Darrick J. Wong
2024-12-04  8:24   ` Christoph Hellwig
2024-12-05  6:14     ` Darrick J. Wong
2024-12-05  6:46       ` Christoph Hellwig
2024-12-05  7:16         ` Darrick J. Wong
2024-12-04  3:02 ` [PATCH 2/6] xfs: don't crash on corrupt /quotas dirent Darrick J. Wong
2024-12-04  8:24   ` Christoph Hellwig
2024-12-04  3:03 ` [PATCH 3/6] xfs: check pre-metadir fields correctly Darrick J. Wong
2024-12-04  8:25   ` Christoph Hellwig
2024-12-04  3:03 ` [PATCH 4/6] xfs: fix zero byte checking in the superblock scrubber Darrick J. Wong
2024-12-04  8:27   ` Christoph Hellwig
2024-12-05  5:54     ` Darrick J. Wong
2024-12-05  6:48       ` Christoph Hellwig
2024-12-05  7:17         ` Darrick J. Wong
2024-12-04  3:03 ` [PATCH 5/6] xfs: return from xfs_symlink_verify early on V4 filesystems Darrick J. Wong
2024-12-04  8:27   ` Christoph Hellwig
2024-12-04  3:03 ` [PATCH 6/6] xfs: port xfs_ioc_start_commit to multigrain timestamps Darrick J. Wong
2024-12-04  4:01   ` Jeff Layton
2024-12-04  8:28   ` Christoph Hellwig
2024-12-05  1:26 ` [PATCHSET v2] xfs: proposed bug fixes for 6.13 Bill O'Donnell
2024-12-05  6:42   ` Darrick J. Wong
2024-12-05  6:52     ` Bill O'Donnell
2024-12-05  6:58       ` Christoph Hellwig
2024-12-05  7:04         ` Bill O'Donnell
2024-12-05  7:30           ` Bill O'Donnell
2024-12-05  7:39             ` Darrick J. Wong
2024-12-05  7:33           ` Darrick J. Wong
2024-12-05  7:40             ` Bill O'Donnell
2024-12-05  7:46             ` Bill O'Donnell
2024-12-05  8:02               ` Bill O'Donnell
2024-12-05  8:39                 ` Greg KH [this message]
2024-12-05  8:47                   ` Bill O'Donnell
2024-12-05  7:57         ` Darrick J. Wong
2024-12-05 16:11     ` Bill O'Donnell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2024120533-dirtiness-streak-c69d@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=bodonnel@redhat.com \
    --cc=cem@kernel.org \
    --cc=djwong@kernel.org \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=jlayton@kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox