Bcachefs Fixes Pull Once Again Frustrates Linus Torvalds - Two Choices Offered

[mdedetrich]

Will the kent stans admit: 1) there is automated testing of be systems 2)

Its by definition not automated as the patches have to be manually submitted and there isn't even a dashboard that indicates when the builds finish and the status of the builds.

it's reasonable for patches to be in linux-next for at least a week before rc1 window opens?

Thats not really reasonable at all for standard software development cadance because it means you only get feedback whether something builds/runs on an esotoric architecture right before an RC window.

Like from your responses its clear you are not a software developer and don't understand how software development works. Kent is continously working on bcachefs and putting his changes into fs-next. The build that runs in linux-next only occurs a week before an RC which happens roughly once every 3 months, that completely kills the workflow.

This is why every single reasonable open source project has a CI build that runs nightly on the currently in progress branch, which is fs-next. Thats what is reasonable. The current linux process for testing builds is more primitive than the apes we came from.

Because that's the reality that Linus understands, kent is only asking for CI improvements for him so it's easier for him to violate #2 without anyone noticing, which isn't a good sign.

Kent's solution is superior because it means that anyone that submits a change to fs-next will get notified of build failures on the next day rather than having a latency that is literally months.

Seriously how braindead do you need to be to understand that all Kent is trying to do is to just make the builds run more often so that developers figure out sooner when a problem happens

There is no deliberate intention of bypassing any kind of violation. Kent and Linus, unlike you, don't get so triggered by someone "breaking a rule or process" which you seem to have some hard on level fascination with. Processes are there to achieve a result, and if the processes don't achieve the result then they need to be updated and/or replaced.

Linus literally said he only cares that the builds are not broken before a release but he doesn't care that much about how that is achieved, thats why the current process is just a suggestion and the current process does not work well with code that rapdily iterates because you have a single time slot window every few months.

[PuckPoltergeist]

As is clearly evident, you might be reading fsdevel but you have troubles with comprehending what you are reading.

Just one example:

https://lore.kernel.org/linux-fsdevel/[email protected]/

[User29]

Read the fuking mailing list, its not in the nightly fs-next CI, thats precisely the issue

Thank you, I'm quite familiar with the thread.

The main issue is that Kent thinks that he knows best and everyone else is a drooling idiot and he and only he can save the world with his wonderful FS.

Also, after this, I don't know what he thinks about himself and his place in the world (no, my bad, we can clearly see what exactly he thinks about himself and the world):

If you're so convinced you know best, I invite you to start writing your own filesystem. Go for it.

[fitzie]

Its by definition not automated as the patches have to be manually submitted and there isn't even a dashboard that indicates when the builds finish and the status of the builds.



Thats not really reasonable at all for standard software development cadance because it means you only get feedback whether something builds/runs on an esotoric architecture right before an RC window.

Like from your responses its clear you are not a software developer and don't understand how software development works. Kent is continously working on bcachefs and putting his changes into fs-next. The build that runs in linux-next only occurs a week before an RC which happens roughly once every 3 months, that completely kills the workflow.

This is why every single reasonable open source project has a CI build that runs nightly on the currently in progress branch, which is fs-next. Thats what is reasonable. The current linux process for testing builds is more primitive than the apes we came from.



Kent's solution is superior because it means that anyone that submits a change to fs-next will get notified of build failures on the next day rather than having a latency that is literally months.

Seriously how braindead do you need to be to understand that all Kent is trying to do is to just make the builds run more often so that developers figure out sooner when a problem happens

There is no violation of anything. Kent and Linus, unlike you, don't get so triggered by someone "breaking a rule or process" which you seem to have some hard on level fascination with. Processes are there to achieve a result, and if the processes don't achieve the result then they need to be updated and/or replaced.

Linus literally said he only cares that the builds are not broken before a release but he doesn't care that much about how that is achieved, thats why the current process is just a suggestion and the current process does not work well with code that rapdily iterates because you have a single time slot window every few months.

I love how people like to assume facts about me that I know aren't true. I've written plenty of software. but my experience wouldn't teach me to understand the difficulty of the distributed (via maintainers) kernel development model.

linux-next (and therefore fs-next) are specifically a subset of the code that kent is working on, that is targeted for the next release. it switches to the next release once rc1 is released. So if kent has something for 6.12 right now, it doesn't go into next, if he wants it for 6.13 it goes in to next but if it's for some future release beyond 6.13 it doesn't go into next. linus has always talked about developers doing development on their own branches, and they should be busy at work on next release even while he's stabilizing the current release. This works fine and has nothing to do with next, as Kent describes his branch model here, which acknoledges that his for linux-next is a subset of his development branch. : https://lore.kernel.org/lkml/5ypgzehnp2b3z2e5qfu2ezdtyk4dc4gnlvme54hm77aypl3flj @xlpjs7dbmkwu/

I have no idea where you get your idea that linux next own starts build testing the week before rc1. you can see lots of daily testing of linux-next right now https://lore.kernel.org/linux-next/

and Stephen the maintainer of linux-next puts out a daily build test that involves lots of build platforms:

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

This is build testing what will become 6.13-rc1, and while it's obviously complete now, not kent is free to start adding to it right now and that will be build tested right now. you can see the size here. http://neuling.org/linux-next-size.html

I have not doubt that kent wants to improve the CI, and that's a good thing, but it's not an excuse for him putting things in last minute into the release. the automated tests will only go so far, and ultimately if he submits a bug that passes automated testing but still causes a release, and linus looks into the history of the patch in next, and it shows that it was a last minute thing then linus is going to have an issue with that. Now Kent is saying he is editing his patches so it's hard to track down if they were in linux-next because the signatures are all different. These are documented rules, but linus isn't a stickler, and it's only there to ensure his merge process works, and his builds aren't broken.

Look I've said this over and over, it's not that kent doesn't have a point, it's just that his perfectly valid point doesn't excuse him breaking a totally reasonable rule that would have prevented this issue. As you've stated that you don't think it's reasonable for linus to want submissions to him to soak in linux-next (and because you are resorting to constant insults and false assumptions), then I won't continue this conversation. Have a great day!

[Daktyl198]

being only able to find out once every 3 months that your code doesn't build on an architecture which literally no one manufacturers anymore is a fuken terrible way to work, it should be a nightly CI run.

You keep saying this, despite being proven wrong. The IBM-z system is actively manufactured, and in use. The newest model was literally announced this year ffs. It's a popular system. Just because your favorite project doesn't care about it doesn't mean others don't. I'd even go so far as to say that far, FAR more people use and care about IBM-z than people who care about bcachefs.

[Daktyl198]

The main issue is that Kent thinks that he knows best and everyone else is a drooling idiot and he and only he can save the world with his wonderful FS.

Also, after this, I don't know what he thinks about himself and his place in the world (no, my bad, we can clearly see what exactly he thinks about himself and the world):

My favorite part of that quote is that Linus did write several filesystem drivers at the very start of Linux.

[mdedetrich]

You keep saying this, despite being proven wrong. The IBM-z system is actively manufactured, and in use. The newest model was literally announced this year ffs. It's a popular system. Just because your favorite project doesn't care about it doesn't mean others don't. I'd even go so far as to say that far, FAR more people use and care about IBM-z than people who care about bcachefs.

Learn to read. I said that the only systems with big endian are either decades old OR are mainframes. IBM-z system is a mainframe, I don't think its realistic to expect Kent to dump hundreds of thousands, if not millions to buy a mainframe for his home but I could be wrong.

Maybe you can buy an ibm-z mainframe and send it to him

My favorite part of that quote is that Linus did write several filesystem drivers at the very start of Linux.

And when Linus wrote this filesystems, these processes didn't even exist something that Kent ironically pointed out to him

[gotar]

It seems like a lot more than the "Experimental" flag is gonna get removed in the next year.

Yeah, the "experimental" flag would go away. One way ...or another.

[cb88]

Wow another drama, actually they are both assholes that think they know better, the one that does not get his patches reviewed and the guy that is stubborn and threatens to remove the hole project is no better.

Pissing on the guy in public doesn't exactly make people want to review his patches more either... this SHOULD have been a call to other interested developers to review Kent's patches more rather than lambasting him for what OTHER people are not doing.

I mean what do you expect the guy to do let his fixes languish forever while your mainline kernel trots ahead...

[gotar]

If only bcachefs was written in rust.. we wouldn't have all this drama...

You're wrong. Such filesystem (CoW, multidevice) is prone to logic errors (including out-of-code - like hardware, races), not only memory management ones.
And if some safeguards are not spotted on time, you'll have to change on-disk format eventually (btrfs case).