Bcachefs Squeezes Last Minute Feature Work Into Linux 6.8

[quaz0r]

boss

subordinate

I picture this guy sitting at a keyboard in a crotchless gimp outfit

[cl333r]

I picture this guy sitting at a keyboard in a crotchless gimp outfit

You make it seem like there are people in this forum who don't.

[NotMine999]

You make it seem like there are people in this forum who don't.

L O L

[fitzie]

EDIT: fitzie you got me to it! 😅

I'm glad you still posted too, it will deflect some of the criticism I get for pointing out Kent's bad social skills.

[fitzie]

Kent and Linus were talking past each other again. The problem is not that the merge window was closed, but that the changes were inappropriate for the merge window to begin with.



I think it is a shame. Linux and bcachefs are better together, but the developers are wasting a lot of time and energy on their behavior.

I've been sending kent $20 a month for almost six years. And somehow pointing out his obvious weakness on a forum he doesn't read is proof that I don't like him?

image.png

[fitzie]

If yall had actually bothered to look at the linux-next merge logs, you'd see Kent Overstreet did place them in the linux-next repository like he'd been asked to do. What Linus is miffed at is there are a lot of them all at once at practically the last minute in the merge cycle. It's not the first time he's taken someone to task for dumping a large or complex code dump at the last minute, unfortunately it won't be the last. Doing something like that violates the "don't be a dick" Thing even when he's 'technically correct'. (NO! 'Technically correct is the best correct' is just a very poor excuse for being a callous jerk, it's not the 'best kind of correct'!) Any competent boss that has to review submissions for his own deadline is going to be miffed at a subordinate dumping an unanticipated big load on him last minute. It's entirely correct for the boss to give the subordinate a talking to. No one functions in a vacuum. Practicing empathy for your collaborative partners isn't an option if you want to remain on their good side (and yes, Linus had to learn this, too.)

this is just not the issue at all. linus isn't saying that kent skipped linux-next (which it turns out he did), he is saying that there is non-bug fixes being added to the bcachefs submission that were created after the merge window opened. the rule is pretty simple, all development targeting a kernel release should switch to bug fixes as soon as the merge window opens, and ideally days before the window opens so it has time to bake in linux-next.

As for whether this stuff ever hit linux-next, let's take a look merge logs for linux-next, it seems not all of the patches kent submitted even made it into the the latest linux-next before he submitted them to linus. So even if that was the issue kent didn't follow any rules.

linux next as of 2024-01-19 (last linux-next before window closed) https://lore.kernel.org/lkml/2024011...b.auug.org.au/

* Merging bcachefs/for-next (1d1edd147cbd bcachefs: opts->compression can now also be applied in the background)

linux next as of 2024-01-11 (linux-next 3 days after the window opened) https://lore.kernel.org/lkml/2024011...b.auug.org.au/

* Merging bcachefs/for-next (169de41985f5 bcachefs: eytzinger0_find() search should be const)

linux next as of 2024-01-22 (linux-next that finally includes all the patches) https://lore.kernel.org/lkml/2024012...uug.org.au/

Merging bcachefs/for-next (249f441f83c5 bcachefs: Improve inode_to_text())


you can see all these commits on the tree he sent to linus to see what patches were not in linux-next when.

https://evilpiepirate.org/git/bcachefs.git/log/?h=bcachefs-2024-01-21

[fitzie]

Actually Kent did submit the changes into linux-next as is expected. The issue seems to stem from the fact that he submitted a big list of changes in last minute before merge window (and according to his latest response he seems to have misremembered when precisely that merge window was).

Anyways this is all hot air.

this is not in any way true and misses the point llnus made.

[Quackdoc]

for anyone who cares, since bcachefs made it into kernel 6.7, you should be able to easily just use a DKMS file now to pull the latest git changes, even if they don't make it for the window, I have a really basic pkgbuild script here for bcachefs-git, but it's largely "untested" since I don't actually follow the git changes so I don't know whats new but dkms reports it loaded, and modinfo does report it as dkms, so it should be fine? At the very least, someone who does follow the development of bcachefs should be able to check fairly easily

https://github.com/Quackdoc/pkgbuild-scripts/tree/Master/bcachefs-git

[oleid]

sadly a recent 50% performance optimization did not make this release. https://lore.kernel.org/linux-bcache...ek5vmisbu/T/#t

Amazing that the sorting algorithm lives inside the driver and not in some utility library😅

[varikonniemi]

Amazing that the sorting algorithm lives inside the driver and not in some utility library😅

It's a side-effect of the Linux dev team wanting to minimize the intrusiveness of the bcachefs merge.

If you look at the comments, it looks like it will be moved out to common infrastructure, and if i'm not mistaken they look to fix several other in-baked implementations in other areas of the kernel by porting them over to the upcoming common implementation as well.