DTPM "Avoid Burning Yourself" Framework Diverted From Linux 5.11

[phoronix]

Phoronix: DTPM "Avoid Burning Yourself" Framework Diverted From Linux 5.11

Yesterday I wrote about the DTPM framework being sent in for Linux 5.11 but ultimately Linus Torvalds has decided not to accept it out of the merge window...

http://www.phoronix.com/scan.php?pag...-In-Linux-5.11

[rabcor]

Woot! He slammed down his fist on this shit after all! I knew he wouldn't be enthusiastic about such a pointless feature merged in the kernel

[oiaohm]

Woot! He slammed down his fist on this shit after all! I knew he wouldn't be enthusiastic about such a pointless feature merged in the kernel

No Linus issue was that it was a new feature outside the merge window for new features. Also this feature has not had the generate 3 months in development trees to possible detect hidden issues. So next merge window it should tick the boxes.

[rabcor]

No Linus issue was that it was a new feature outside the merge window for new features. Also this feature has not had the generate 3 months in development trees to possible detect hidden issues. So next merge window it should tick the boxes.

That's the given reason, yes. But

After initially questioning the "very much a non-fix thing", he ultimately pulled in a revised merge request that lacked the DTPM framework addition.

He doesn't like it.

[onlyLinuxLuvUBack]

That's the given reason, yes. But



He doesn't like it.

He gave it the "nvidia-finger"

[F.Ultra]

That's the given reason, yes. But



He doesn't like it.

The revised merge that he pulled in was a fix so no you are reading this wrong.

[oiaohm]

After initially questioning the "very much a non-fix thing", he ultimately pulled in a revised merge request that lacked the DTPM framework addition.

He doesn't like it.

That not Linus does not like it. Linux kernel has rules. Non-fix thing means you have added a feature instead of a bug fix after the merge window for new features is closed for the particular kernel version. Historically this rule can be bi-passed if you can prove that its a critical feature to fix some issue but it does have some major costs. Now thing that is fun about the Non-fix thing is Linus back in the day has had to pull a patch he made himself because it was after the window close for new features and it was a new feature.

This was a process problem not Linus having like or hate for the patch.

Rabcor over a 3 month Linux kernel rough release pattern there is a 2 week time frame for new features. If new feature is submitted in that 2 weeks it is reviewed for include for mainline. If you miss that two weeks you have to wait for the next one in roughly 3 months time. Linus and the Linux kernel does have very strict rules on this you feature include in the Linux kernel can be pushed back 3 months because it turns up on the mailing list 1 min late(yes this has happened may times). Linus has been a lot more polite about it than the past.

Hard point the one attempting to submit DTPM for 5.11 missed the window for a new feature by days. Remember 1 min past the dead line is rejection for this Linux kernel version. This has absolute no bearing if it will be accepted next time. This is not hate by Linus. Hurding the cats that are Linux kernel developers the only way Linus can do it is with strict rules on when you can add features as well when you have to be bug fixing. New features also normally results in needing new test suite.

See problem yet allowing a new feature that has missing 2 weeks for bad for the following reasons
1) the jobs making test suite parts to cover the new features are handed out though that 2 weeks with the hopefully final in kernel testsuite finished 2 weeks after that. This is a big one allowing a new feature past the dead line can push the Linux kernel release date back. The record in Linux history of this going horrible wrong is one release cycle that is 6 months instead of 3 months. Yes Linus knows this history he was there for it.
2) If you let one person past the dead line everyone will want to be past the dead line the pack of sheep and open gate problem. So this means Linus has to enforce this rule no matter what he thinks of the patch. If he does not he will have chaos on his hands. Linus cannot allow stuff into Linux kernel mainline that is released at the wrong time unless there is some clear justification clean justification would mean that something like DTPM is like important enough that it would have to be back-ported into all the LTS branches for some critical reason so this is a very high bar and has to be.

So this absolutely not that the feature is not liked. Its more its been released at the wrong time. Please note Linus asked question not just straight up rejected the patch set. If Linus did not like the patches he would not asked question allowing possible debate about some procedural issue instead it would have been a simple that patch set is rejected please redo it. Linus asking questions costs Linus time he does not have very much free time in the main cycles.

This looks like a non-fix thing from Linus really opened the door for the one submitting to DTPM patch set to say on X,Y,Z hardware in production this feature is required to fix bug so they function correctly so after mainline it will need to be backported to the LTS branches if example like that could be proven this would open up the exception to allow late feature add. This arguement is no possible so new feature has to wait to next Linux kernel version.

The fact Linus asked a question means he does not absolutely hate it. Linus not absolutely hating something does not mean he likes it either.