> Minimally, I would like context for the change, …
… the why is important
> IMO many software developers … don't have explanations to provide. People not taking the time is what makes reviews performative.
… a lot of developers only consider the how.
i’ve had a lot of experiences of “once my PR is submitted that’s my work/ticket finished” kind of attitude.
i spent a year mentoring some people in a gaming community to become dev team members. one of the first things i said about PRs was — a new PR is just your first draft, there is still more work to do.
it helped these folks were brand spanking new to development and weren’t sullied by some lazy teacher somewhere.
> … the why is important
> … a lot of developers only consider the how.
The why is someone else's job, so the developers should just ask them for a blurb to put in the PR for context, along with a note to the reviewer to ask that person for even more context if necessary.
I think there's a why with regard to the code. Why this "how" and not some other "how". (Why did you pick this algorithm, this pattern, this solution to the bigger business why.)
> In practice bcachefs is used in production with real users. If the experimental label prevents critical bug fixes from making it into the kernel then it would be better to just remove that label.
alternative perspective: those users have knowingly and willingly put experimental software into production. it was their choice, they were informed of the risk and so the consequences and responsibility are their’s.
it’s like signing up to take some experimental medicine, and then complaining no-one told me about the side-effect of persistent headaches.
that doesn’t stop anyone from being user-centric in their approach, e.g. call me if you notice any symptoms and i’ll come round your house to examine you.
… as long as everyone is clear about the fact it is experimental and the boundaries/limitations that apply, e.g. there will be certain persistent headache medicines that cannot be prescribed to you, or it might take longer for them to work because you’re on an experimental medicine.
Again: the elephant in the room is that a lot of bcachefs users are using it explicitly because they have lost a lot of data on btrfs, and they've found it to be more trustworthy.
This puts us all in a shitty situation. I want the experimental label to come off at the right time - when every critical bug is fixed and it's as trustworthy as I can reasonably make it, when I know according to the data I have that everyone is going to have a good experience - but I have real users who need this thing and need to be supported.
There is _no reason_ to interpret the experimental label in the way that you're saying, you're advocating that reliability for the end user be deprioritized versus every other filesystem.
But deprioritizing reliability is what got us into this mess.
>users are using it explicitly because they have lost a lot of data on btrfs
PLEASE, honestly, EDUCATE THESE USERS. This is still marked experimental for numerous reasons regardless of the 'planned work for 6.18'. Users who can't suffer any data loss and are repeating their mistake of using btrfs shouldn't be using a none default/standard/hardened filesystem period.
No, really. People aren't losing data on bcachefs. We still have minor hiccups that do affect usability, and I put a lot of effort into educating users about where we're at and what to expect.
In the past I've often told people who wanted to migrate off of btrfs "check back in six months", but I'm not now because 6.16 is looking amazingly solid; all the data I have says that your data really is safer on bcachefs than btrfs.
I'm not advocating for people to jump from ext4/xfs/zfs, that needs more time.
You're arguing in circles. Either bcachefs is experimental and hence needs a lot of changes and tools to make sure that users dont lose data and hence the fixes are not critical/users can use a custom branch. Or it is stable and the only thing users need is actual big fixes. Not new tools in an RC3.
Don't compare bcachefs with btrfs for stability. Compare it with ext4. (And dont care anecdotal data, compare the process).
Kent, whenever you're at a point where you could make a good decision and make progress on any non-technical axis, you choose to attack something or someone. This is why you're getting the reactions you are getting. bcachefs design looks good, literally everything else about the project is miserable, because of this.
Now, I fully expect you to react poorly to this message, too. That is the expectation the world has formed of you. Think about that.
> what about an original human-generated text that is entirely translated by an AI?
probably ai-modified -- the core content was first created by humans, then modified (translated into another language). translating back would hopefully return you the original human generated content (or at least something as close as possible to the original).
| class | author | modifier/reviewer |
| ----------------- | ------ | ----------------- |
| none | human | human/none |
| ai-modified | human | ai | <--*
| ai-originated | ai | human |
| machine-generated | ai | ai/none |
you do realise that most people slow down for blind curves for exactly this reason, right?
pre-empt potential dangers and adjust driving accordingly. if you’re concerned that you might have to act due to an unseen/unknown danger — then slow down.
it shouldn’t be necessary to swerve out when driving except as a choice of absolute last resort (ie something/someone jumped in front of you inside braking distance and you’ve got no other safe option, in which case you’re probably fucked anyway).
> fewer chargers, less e‑waste, less drawer chaos.
care to mention what negates those things to make it a “not good” regulation?
as a consumer, i think it’s a good thing to not need Nx different charging cables / plugs to go away for a weekend. usb-c is basically the de-facto standard for charging all but apple devices anyway.
hardware manufacturers might have a different opinions/motivations (but that was kind of the point really wasn’t it)
Everything seemed to have been moving towards USB-C regardless for a few years now, so it seems somewhat superfluous at this point in time? Apple was a major holdout though, due to Apple reasons.
Not strongly against it as such, but also not entirely convinced it's needed either.
Well I did say "somewhat superfluous", not "entirely superfluous" :-)
This is where the up- and down-sides need to be considered. Everyone moved from micro-USB to USB-3 because it was easier and better, and this will now be harder (not impossible, as another comment says, this is supposed to be evaluated 5 years). There may also be special cases where there's a good reason to use something other than USB-C Is that a big problem? Maybe not? I don't know.
… the why is important
> IMO many software developers … don't have explanations to provide. People not taking the time is what makes reviews performative.
… a lot of developers only consider the how.
i’ve had a lot of experiences of “once my PR is submitted that’s my work/ticket finished” kind of attitude.
i spent a year mentoring some people in a gaming community to become dev team members. one of the first things i said about PRs was — a new PR is just your first draft, there is still more work to do.
it helped these folks were brand spanking new to development and weren’t sullied by some lazy teacher somewhere.