Message-ID: <3366564.44csPzL39Z@lichtvoll.de>
Date: Fri, 20 Jun 2025 09:12:21 +0200
From: Martin Steigerwald <martin@...htvoll.de>
To: Jani Partanen <jiipee@...apeli.fi>,
 Kent Overstreet <kent.overstreet@...ux.dev>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
 linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] bcachefs fixes for 6.16-rc3

Hi Kent, hi,

Kent Overstreet - 20.06.25, 03:51:45 CEST:
> On Fri, Jun 20, 2025 at 04:25:58AM +0300, Jani Partanen wrote:
> > On 20/06/2025 4.09, Kent Overstreet wrote:
> > > I'm not seeing that _you_ get that.
> > 
> > How hard it is?
> > 
> > New feature window for 6.16 was 2 weeks ago.
> > 
> > rc<insert number here> is purely for fixing bugs, not adding new
> > features and potential new bugs.
> 
> That's an easy rule for the rest of the kernel, where all your mistakes
> are erased at a reboot. Filesystems don't have that luxury.
> 
> In the past, I've had to rush entire new on disk format features in
> response to issues I saw starting to arise - I think more than once, but
> the btree bitmap in the member info section was the big one that sticks
> in my mind; that one was very hectic, but 100% proved its worth.

Kent, from what I gathered, you'd like to change some window rules – at 
least for filesystems or new-in-kernel filesystems.

And from what I observed: You try to do so by just not adhering to at 
least one of those rules at least once in a while. Maybe for a good 
reason, but still, you just do not adhere to the rule of only fixes. Or at 
the very least, you define a fix to be something that is (way) more than a 
fix for other kernel developers.

It may make sense to change some merge window rules or it may not, I don't 
know. However… from what I observe:

Just unilaterally changing a rule or redefining a word in that rule may 
not be a sustainable and working (!) approach to go about it. Just from 
observing the communication pattern here I conclude that.

I'd rather recommend to bring this up the next opportunity you can discuss 
it with fellow kernel developers, ideally while meeting face to face. 
Cause let's face it: The Linux kernel is a team effort.

If you stick to your approach about merge window rules and many other 
kernel developers including Linus stick to their rules this will go in 
circles.

Indefinitely so.

Not sure whether that is a good use of your time. But your call really.

So how about adhering to the current rules for now and bringing up the 
topic in a meeting you will have at one point in the future?

Just my two cents from observing the repeated (!) communication pattern 
here. Cause it is not at all the first time the discussion arrives exactly 
at this point.

> For a lot of users, compiling a kernel from some random git repository
> is a lot to ask. I spend a lot of time doing what amounts to support;
> that's just how it is these days. But rc kernels are packaged by most
> kernels, and we absolutely do not want to wait an additional 3 months
> for it to show up in a release kernel -

Those users should probably not use BCacheFS right now already to begin 
with but wait for it to be marked as stable?

It reminds my about Debian Unstable users wanting the newest and greatest 
and then complaining that at times some things are not stable. Which is 
the very definition of what can happen in Debian Unstable.

I meanwhile use BCacheFS. On Devuan. But for now that means I have to 
compile BCacheFS tools myself, and better also the kernel to have the 
latest and probably greatest during the hard freeze of Debian.

And I use it for data that is backed up or that I can afford to loose.


And about what you wrote in your previous mail:

Kent Overstreet - 20.06.25, 03:09:07 CEST:
> There are a _lot_ of people who've been burned by btrfs. I've even been
> seeing more and more people in recent discussions talking about
> unrecoverable filesystems with XFS (!).

And I have seen a lot of threads on XFS over the years where XFS 
developers went great lengths to help users recover their data. I have 
seen those threads also on the BTRFS mailing list. Those users had no 
support contract, they did not pay anything for that free service either.

So I am not sure it is wise or even just accurate to implicitly imply that 
other than BCacheFS filesystem developers do not care about user data. 
From what I have seen I conclude: They do!

But maybe that is not even the point: Other filesystems are maintained by 
other people and they do what they think is best. If you like to see a 
change in some merge window rules for what you try to achieve with 
BCacheFS you can independently from what other filesystem developers do 
ask for a slot to talk in one of the next face to face kernel developer 
meetings.

Best,
-- 
Martin

Powered by blists - more mailing lists