At some point you have to draw the line in the sand and say this is what we’re updating to for this release, we’ll update again for the next one. I compare it to Star citizen, who kept updating to the latest and greatest and never delivered a product. I don’t care that you upgraded to the latest engine update, finish the product.
Valid, if they created this update before November 2023 when 6.6 was released, and have needed to test Steam OS with the 6.5 kernel for a whole year before releasing it.
Nope, even then, think of how much QA would go into something like this. They probably have 6-8 months of features that were built on this kernel. Upgrading the kernel before would mean needing to redo everything - all of the QA, UAT, months of prep work. Companies who hold up these big releases for us aren’t like us just clicking perform upgrade, it’s a massive process that needs signoffs and confirmations. That’s why I say they probably just drew a line in the sand and said “We can’t risk destabilizing it just to perform an upgrade” - or for all we know they did do the upgrade, realized it broke something critical, and decided against it.
We all know if they rolled out a broken release everyone would be on every forum with pitchforks calling Valve the devil. They weren’t just being idiots by not upgrading.
Always porting not-yet-upstreamed patches to new release kernels is additional work to the upstreaming work towards the latest development tree. The Valve engineers interviewed around the very first Steam Deck announcement said their goal with moving from Debian to Arch was to minimize the patchset maintenance burden. Their approach surely has that goal in mind. There are only two variants of Steam Deck with minor differences between them. If backporting patches from newer kernels is less work than forward porting their patches, they just stay with that version for a while. Updates to drivers for hardware they don’t use and filesystems they don’t use aren’t relevant to them anyway.
Weird that they went to kernel 6.5 which is already a year old, rather than going to the LTS version 6.6 which is still in support.
At some point you have to draw the line in the sand and say this is what we’re updating to for this release, we’ll update again for the next one. I compare it to Star citizen, who kept updating to the latest and greatest and never delivered a product. I don’t care that you upgraded to the latest engine update, finish the product.
Valid, if they created this update before November 2023 when 6.6 was released, and have needed to test Steam OS with the 6.5 kernel for a whole year before releasing it.
Nope, even then, think of how much QA would go into something like this. They probably have 6-8 months of features that were built on this kernel. Upgrading the kernel before would mean needing to redo everything - all of the QA, UAT, months of prep work. Companies who hold up these big releases for us aren’t like us just clicking perform upgrade, it’s a massive process that needs signoffs and confirmations. That’s why I say they probably just drew a line in the sand and said “We can’t risk destabilizing it just to perform an upgrade” - or for all we know they did do the upgrade, realized it broke something critical, and decided against it.
We all know if they rolled out a broken release everyone would be on every forum with pitchforks calling Valve the devil. They weren’t just being idiots by not upgrading.
Always porting not-yet-upstreamed patches to new release kernels is additional work to the upstreaming work towards the latest development tree. The Valve engineers interviewed around the very first Steam Deck announcement said their goal with moving from Debian to Arch was to minimize the patchset maintenance burden. Their approach surely has that goal in mind. There are only two variants of Steam Deck with minor differences between them. If backporting patches from newer kernels is less work than forward porting their patches, they just stay with that version for a while. Updates to drivers for hardware they don’t use and filesystems they don’t use aren’t relevant to them anyway.