Bcachefs Squeezes Last Minute Feature Work Into Linux 6.8

[oleid]

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

I see, that makes sense, thanks.

[Raka555]

This guy has been working tirelessly for years on something that he is passionate about and that will benefit many people.

I don't get why people are trying to point out flaws in his personality. None of us are perfect.

Next time you are reporting on "his flaws", please state what you have done to make linux/opensource better for everyone...

[Quackdoc]

This guy has been working tirelessly for years on something that he is passionate about and that will benefit many people.

I don't get why people are trying to point out flaws in his personality. None of us are perfect.

Next time you are reporting on "his flaws", please state what you have done to make linux/opensource better for everyone...

i rEpOrTeD An iSsUe!

[fallingcats]

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.

If that's true the kernel team failed badly at naming, because that's widely known as a feature freeze. When someone has patches ready _inside the merge window_ then they're in time per definition. They shouldn't be called late and they should be called a dick for cutting it close either.

[fitzie]

If that's true the kernel team failed badly at naming, because that's widely known as a feature freeze. When someone has patches ready _inside the merge window_ then they're in time per definition. They shouldn't be called late and they should be called a dick for cutting it close either.

yes, you can read linus explaining this here: https://lore.kernel.org/lkml/CAHk-=w...ail.gmail.com/

Yes, the merge window is two weeks, but that's very much to allow me
time to look things over, not "two weeks to hurriedly put together a
branch that you send Linus on Friday of the second week". The whole
"do an all-nighter to get the paper in the day before the dealine" is
something that should have gone out the window after highschool. Not
for kernel development.

The rule is that things that get sent to me should be ready *before*
the merge window opens, not be made ready during the merge window.
With some slack for "life happens", of course, but I really get the
feeling that a few people treat the end of the merge window as a
deadline, missing the whole "it was supposed to be ready before the
merge window".