Message-ID: <32cn5wzlryvq7z64uwo3ztooh7rthlp2ihmbgfyayvehtdbeyt@pnvumkjz4eve>
Date: Sun, 21 Jan 2024 07:20:32 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Theodore Ts'o <tytso@....edu>
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 Wed, Jan 17, 2024 at 09:49:22PM -0500, Theodore Ts'o wrote:
> On Wed, Jan 17, 2024 at 08:03:35AM -0500, James Bottomley wrote:
> > Actually, this is partly our fault.  Companies behave exactly like a
> > selfish contributor does:
> > 
> > https://archive.fosdem.org/2020/schedule/event/selfish_contributor/
> > 
> > The question they ask is "if I'm putting money into it, what am I
> > getting out of it".  If the answer to that is that it benefits
> > everybody, it's basically charity  to the entity being asked (and not
> > even properly tax deductible at that), which goes way back behind even
> > real charitable donations (which at least have a publicity benefit) and
> > you don't even get to speak to anyone about it when you go calling with
> > the collecting tin.  If you can say it benefits these 5 tasks your
> > current employees are doing, you might have a possible case for the
> > engineering budget (you might get in the door but you'll still be
> > queuing behind every in-plan budget item).  The best case is if you can
> > demonstrate some useful for profit contribution it makes to the actual
> > line of business (or better yet could be used to spawn a new line of
> > business), so when you're asking for a tool, it has to be usable
> > outside the narrow confines of the kernel and you need to be able to
> > articulate why it's generally useful (git is a great example, it was
> > designed to solve a kernel specific problem, but not it's in use pretty
> > much everywhere source control is a thing).
> 
> I have on occasion tried to make the "it benefits the whole ecosystem"
> argument, and that will work on the margins.  But it's a lot harder
> when it's more than a full SWE-year's worth of investment, at least
> more recently.  I *have* tried to get more test investment. with an
> eye towards benefitting not just one company, but in a much more
> general fasion ---- but multi-engineer projects are a very hard sell,
> especially recently.  If Kent wants to impugn my leadership skills,
> that's fine; I invite him to try and see if he can get SVP's cough up
> the dough.  :-)

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?"

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?

If I sound frustrated, it's because I am.

> I've certainly had a lot more success with the "Business quid pro quo"
> argument; fscrypt and fsverity was developed for Android and Chrome;
> casefolding support benefited Android and Steam; ext4 fast commits was
> targetted at cloud-based NFS and Samba serving, etc.

Yeah, I keep hearing you talking about the product management angle and
I have to call bullshit. There's a lot more to maintaining the health of
projects in the long term than just selling features to customers.

> Unfortunately, this effect fades over time.  It's a lot easier to fund
> multi-engineer projects which run for more than a year, when a company
> is just starting out, and when it's still trying to attract upstream
> developers, and it has a sizeable "investment" budget.  ("IBM will
> invest a billion dollars in Linux").  But then in later years, the
> VP's have to justify their budget, and so companies tend to become
> more and more "selfish".  After all, that's how capitalism works ---
> "think of the children^H^H^H^H^H^H^H shareholders!"

This stuff doesn't have to be huge multi engineer-year projects to get
anything useful done.

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?

Powered by blists - more mailing lists