Rolling stable kernels

2 Antworten [Letzter Beitrag]
Beigetreten: 09/13/2010

Should I be doing this with Linux-libre somehow? Yes? No? In addition to the current stuff or in place of? Discuss!

Lèyon di li N.
Beigetreten: 02/11/2017

“Levin called this the "finger and toes" version-number scheme, because Torvalds said that he could count up to around 20 "minor" releases before running out of digits and needing to increase the major version number.”
What? I can count from 0 to 5 with the fingers from one hand and and same with the other, but my toes looks like inefficient, so, I personally only can go from 0 to 35 (0 to 5 is 6 cyphers and 6 × 6 = 36 and to take in account 0: 36 - 1 = 35, so that leads to that result); so, if he is still good with his toes he could be able to count from 0 to 120 (as you can count from 0 to 10 with both fingers, same with the toes when you can, that makes 11 cyphers each, so 11 × 11 = 121 and 121 - 1 = 120).
So, just go up to 5.35, then it is 6.0 and so on and when 35.35 is reached, the next version is 0.0.
OK, joke done, back to serious stuffs:
‘The idea is to use "Git magic" to make it all work; there is no cherry picking of patches. Instead a "hack on Git merges" is used, which preserves the SHA1 values as they are in the existing stable branches. The Git tags survive and the SHA1 preservation means that the folks doing verification to prevent supply-chain attacks can do so more easily. Bisection still works, authors don't change so Git blame works, and so on. The stable maintainers just "manipulate Git a little bit to give the appearance that all this development happened in a single branch", he said. It is simply a change in "how we present kernel trees to the end user".
Currently, users will be on a stable branch or an LTS branch, but under this model, they would instead be on the stable or LTS branch. They are not using some random kernel version, but are instead using the version that the kernel developers have recommended for the best experience. From that, they will get all of the latest features, bug fixes, and security updates.’
Err, I got lost their, I just don't understand the result of that.
‘Another area of worry is that the rolling model effectively "masks the merge window inside of it". One day the rolling stable tree might be on 5.7.15 and the next on 5.8.1; within that pull are a lot of patches that are from the 5.8 merge window, which is a big step. But it all goes back to testing, he said; it is possible that the merge window introduced a lot of bugs, but it is also possible that a single stable patch does the same thing.’
I don't understand either, probably because I got lost a bit before. But, whatever, it looks problematic.
My little thought on that is that: what is sure is that the actual model is effectively problematic and that Long Time Support version is a a bad idea because of the way the kernel is released on time schedule and the fact that the Long Time Support version is randomly chosen (if I got it right) and also a good idea because supporting a product on long term is a good thing, so my humble suggestion would be that they might choose backward each x time between all recent enough version (in a length of time that they choose) what will be the long supported one based on how it might be worth to be sustained (on the best criteria they might think of). Also, they might support the Long Tim Support version for as long as it's not too tricky to maintain it instead of maintaining it for x years. But not being involved in that project, maybe what I suggest is just not realistic or wrong in whatever way.
And concerning your question, I think that Linux-libre should not bother (by the way, how are you involved in Linux-libre?) and just follow what they do, because, users are so poorly informed about this (I once heard, I thing some times around 2005 about the Linux numbering problem but don't even remember what resulted from that back then) that what will be explained by the Linux developers will be what must be explained to the users not to add more confusion, so, once again, whatever this is a good thing or not, Linux-libre should just follow what they do, this is just version numbering, that's not a big deal even though it might be a wrong way to do things (by the way, is there a good way to number Linux?).

Beigetreten: 04/01/2021

Took forever before I could process that thread, had to reboot brains many times, but finally managed to pick my favorite comment on the topic:

"What I suspect would happen if such a rolling update became popular is that users would start to implore stable maintainers "not to merge the new one yet", so we'll get an new-LTS, current-LTS, previous-LTS and older-LTS rolling updates. Right now these are called "5.10", "5.4", "4.19", "4.9" and so on."