Message-ID: <20240124055201.GA2125008@mit.edu>
Date: Wed, 24 Jan 2024 00:52:01 -0500
From: "Theodore Ts'o" <tytso@....edu>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: James Bottomley <James.Bottomley@...senpartnership.com>,
        Greg KH <greg@...ah.com>, Mark Brown <broonie@...nel.org>,
        Neal Gompa <neal@...pa.dev>, Kees Cook <keescook@...omium.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org,
        Nikolai Kondrashov <spbnick@...il.com>,
        Philip Li <philip.li@...el.com>, Luis Chamberlain <mcgrof@...nel.org>
Subject: Re: [GIT PULL] bcachefs updates for 6.8

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

Powered by blists - more mailing lists