From: "Theodore Ts'o" <tytso@mit.edu>
To: Kent Overstreet <kent.overstreet@linux.dev>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
Greg KH <greg@kroah.com>, Mark Brown <broonie@kernel.org>,
Neal Gompa <neal@gompa.dev>, Kees Cook <keescook@chromium.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-bcachefs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
Nikolai Kondrashov <spbnick@gmail.com>,
Philip Li <philip.li@intel.com>,
Luis Chamberlain <mcgrof@kernel.org>
Subject: Re: [GIT PULL] bcachefs updates for 6.8
Date: Wed, 24 Jan 2024 00:52:01 -0500 [thread overview]
Message-ID: <20240124055201.GA2125008@mit.edu> (raw)
In-Reply-To: <32cn5wzlryvq7z64uwo3ztooh7rthlp2ihmbgfyayvehtdbeyt@pnvumkjz4eve>
On Sun, Jan 21, 2024 at 07:20:32AM -0500, Kent Overstreet wrote:
>
> Well, I've tried talking to you about improving our testing tooling - in
> particular, what we could do if we had better, more self contained
> tools, not just targeted at xfstests, in particular a VM testrunner that
> could run kselftests too - and as I recall, your reaction was pretty
> much "why would I be interested in that? What does that do for me?"
My reaction was to your proposal that I throw away my framework which
works super well for me, in favor of your favorite framework. My
framework already supports blktests and the Phoronix Test Suite, and
it would be a lot less work for me to add support for kselftests to
{gce,kvm,android}-xfstests.
The reality is that we all have test suites that are optimized for our
workflow. Trying to get everyone to standardize on a single test
framework is going to be hard, since they have optimized for different
use cases. Mine can be used for both local testing as well as
sharding across multiple Google Cloud VM's, and with auto-bisection
features, and it already supports blktests and PTS, and it handles
both x86 and arm64 with both native and cross-compiling support. I'm
certainly willing to work with others to improve my xfstests-bld.
> So yeah, I would call that a fail in leadership. Us filesystem people
> have the highest testing requirements and ought to know how to do this
> best, and if the poeple with the most experience aren't trying share
> that knowledge and experience in the form of collaborating on tooling,
> what the fuck are we even doing here?
I'm certainly willing to work with others, and I've accepted patches
from other users of {kvm,gce,android}-xfstests. If you have something
which is a strict superset of all of the features of xfstests-bld, I'm
certainly willing to talk.
I'm sure you have a system which works well for *you*. However, I'm
much less interested in throwing away of my invested effort for
something that works well for me --- as well as other users of
xfstests-bld. (This includes other ext4 developers, Google's internal
prodkernel for our data centers, and testing ext4 and xfs for Google's
Cloud-Opmized OS distribution.)
This is not a leadership failure; this is more like telling a Debian
user to throw away their working system because you think Fedora
better, and "wouldn't it be better if we all used the same
distribution"?
> ktest has been a tiny side project for me. If I can turn that into a
> full blown CI that runs arbitrary self contained VM tests with quick
> turnaround and a nice git log UI, in my spare time, why can't we pitch
> in together instead of each running in different directions and
> collaborate and communicate a bit better instead of bitching so much?
xfstests-bld started as a side project to me as well, and has
accumulated other users and contributors. Why can't you use my system
instead? By your definition of "failure of leadership", you have
clearly failed as well in not seeing the light and using *my* system. :-)
- Ted
next prev parent reply other threads:[~2024-01-24 5:52 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-10 19:36 [GIT PULL] bcachefs updates for 6.8 Kent Overstreet
2024-01-10 23:48 ` Kees Cook
2024-01-11 0:04 ` Kent Overstreet
2024-01-11 0:39 ` Kees Cook
2024-01-11 0:58 ` Kent Overstreet
2024-01-11 1:47 ` Linus Torvalds
2024-01-11 22:57 ` Matthew Wilcox
2024-01-11 23:42 ` Kees Cook
2024-01-11 23:58 ` Linus Torvalds
2024-01-12 0:05 ` Kent Overstreet
2024-01-12 0:18 ` Kees Cook
2024-01-11 15:35 ` Mark Brown
2024-01-11 17:38 ` Kent Overstreet
2024-01-11 21:47 ` Mark Brown
2024-01-12 1:10 ` Kent Overstreet
2024-01-12 11:11 ` Neal Gompa
2024-01-12 18:22 ` Mark Brown
2024-01-15 18:42 ` Kent Overstreet
2024-01-15 20:13 ` Greg KH
2024-01-17 4:41 ` Kent Overstreet
2024-01-17 5:31 ` Greg KH
2024-01-17 5:54 ` Theodore Ts'o
2024-01-17 13:03 ` James Bottomley
2024-01-17 18:19 ` Mark Brown
2024-01-21 3:24 ` Kent Overstreet
2024-01-25 21:46 ` Mark Brown
2024-01-18 2:49 ` Theodore Ts'o
2024-01-21 12:20 ` Kent Overstreet
2024-01-24 5:52 ` Theodore Ts'o [this message]
2024-01-18 5:35 ` Randy Dunlap
2024-01-21 2:49 ` Kent Overstreet
2024-01-17 17:33 ` Mark Brown
2024-01-11 2:23 ` pr-tracker-bot
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=20240124055201.GA2125008@mit.edu \
--to=tytso@mit.edu \
--cc=James.Bottomley@hansenpartnership.com \
--cc=broonie@kernel.org \
--cc=greg@kroah.com \
--cc=keescook@chromium.org \
--cc=kent.overstreet@linux.dev \
--cc=linux-bcachefs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=neal@gompa.dev \
--cc=philip.li@intel.com \
--cc=spbnick@gmail.com \
--cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).