Just my 2 cents or Euro equivalent...Debian Stable offers newer kernels via the Backports repo for those instances where the stable kernel (Solus LTS equivalent) doesn't work well. I'm wondering why users with newer hardware would want to use an LTS kernel.
Edit -- Just checked the Debian Testing repos and as of now, the kernel version that would be used in the next stable release would be 5.8.10.x, so maybe it might be a good idea to update the LTS kernel.
I have installed the LTS Kernel and the Current Kernel with zero problems. Including every component package available via Eopkg. All of you have in my opinion made one of the best Linux Distributions available to date. Second to none. Equally as flawless (infer superior to Clear Linux) as the Clear Linux Project from which I very recently migrated even whilst being far more functional versus the more spartan nature of the aforementioned operating system. Congratulations and my thanks to the Core Team accordingly.
DataDrake Seems like 5.10 will be the next LTS.
sothis6881 first we need to get 5.7/5.8 to current rolling so we can even think about 5.10 LTS 
Hope that bugs with 5.7/5.8 will be fixed soon, so many new hardware is released and I'm preordering Ryzen 5900X and RX6900XT, hope Solus team will manage to solve those issues to the end of year. Don't wanna use Manjaro or Fedora as Solus is just a sweet spot for my like.
i'm not developer or maintainer and i don't have expert opinion, but i think the problem with NVMe the problem is with linux firmware and linux current kernel. Once again i'm not an expert, just thoughts on the go
Hey everyone,
Just an update. Today I spent some time trimming down our config to the bare essentials for my machine specifically, to minimize build times as I looked into this issue. With the latest release of 5.10.0-rc1, I opted to test against this, not bothering to immediately rebase our patches in the event it didn't resolve my NVMe namespaces to begin with.
Fortunately, I have some good news. I can confirm that this build of the kernel resolved our NVMe namespaces. After this, I passed it off to @DataDrake and @Girtablulu, which both have similar or identical (depending on the person) Samsung controllers for their NVMe drives as I do, and they both validated that their namespaces were also being resolved and they were able to boot into the desktop! @DataDrake 's logging documentation was also invaluable to validating that it was actually fixed and my initial issues were elsewhere (failing to reach the login screen made me suspicious initially), so massive thanks to him. I would've wasted countless hours otherwise 
From this point, I went and rebased our kernel patches (such as for apparmor confinement, ELANtech touchpad support, etc.) then copied and updated our 5.6 kernel config for 5.10. I've listed some of the features / flags I've enabled below:
Alongside all of this, I grabbed a patch that enables the building of nvidia-glx-driver against 5.10. In all likelihood this can be applied to the other drivers (390, beta, and developer). I've validated that graphics work, as you can see from the screenshot below, and that snaps work as well (in other words, I didn't break the AppArmor confinement, which is always a plus).
Given all of this, it does indeed appear that 5.10 will be the kernel that current will see an update to. That being said, 5.10 isn't scheduled for release until late December, so @DataDrake and I need to determine whether or not we're going to defer Solus 4.2 until then or ship with an RC, given it doesn't appear 5.9 has gotten all the NVMe changes. Obviously we recognize that Solus 4.2 is much needed (we want to release it too!), especially given I'll be starting the GNOME 3.38 upgrade locally next week and Budgie 10.5.2 will be officially released when GNOME 3.38 lands in our stable repo. At that point there won't be any blockers besides the kernel for tagging.
big updates hype !
Updated to 5.10.0-rc2 moments ago locally. Still booting, so that's good 
DataDrake be sure to include this fix if u can
As for some of us
Mate version breaks with latest kernel 
https://discuss.getsol.us/d/4717-display-problem-installing-solus-mate
ghostv33 What fix? LTS is quite a bit older than latest at this point. If someone knows an actual patch that fixes it, we can add it, but "it works on LTS" is literally saying "it used to work, years ago". We have a hard enough time fixing regressions between releases in the same kernel series, weeks apart, let alone the thousands of commits between LTS and now.
ghostv33 I know, I read the other thread. My point is asking us to include the "fix" is like asking us to sort through a haystack for a single needle without lighting the haystack on fire. And since we can't reproduce it ourselves easily, searching that haystack also means not using magnets. It's probably something odd with the display driver in the linux-current kernel for your machine. That likely will only get fixed by moving us to a newer kernel which is waiting on a stable release of 5.10 at the moment.
ghostv33 I know. I figured you could connect the dots that it's specifically something in the driver that is causing problems with MATE's compositor (marco) and not the compositors/WM on the other editions. Apparently, I should have been more clear. These kinds of bugs happen all the time. They are almost always fixed by a later kernel update. Please be patient.
Cooking 5.10-rc3, which will actually fix an issue I've been having with my realtek card on the r8169 driver, so that'll be nice!
JoshStrobl Will your RC builds of the LTS kernel be available in Unstable to test?
I'm hopeful that maybe I can use my 2740p on that without the stability issues I have under Current.
Saijin_Naib 5.10 would be our current, not LTS. Our linux-lts is designed for what we consider older, "legacy" hardware that has notable regressions in newer kernels. The RCs aren't available since they're just on an experimental source repo that we have, not something we're going to be supporting more broadly since it'd require additional driver support, build time, etc. Mostly used as a rare playground to test changes or in this case, just get a head start on 5.10 so we can push it to unstable as soon it's released as a proper stable release.
@DataDrake has a fairly clear idea on how he wants to address LTS going forward. My work / testing is limited to future current.
JoshStrobl Thank you for the clarification.
I will see if/how I may help test the future LTS then.
Saijin_Naib In further testing against current (5.6) on my HP EliteBook 2740p, I find that the issue with suspend/resume remains, and in addition, I am subject to random hard-freezes during usage/idling. Performance seems better than LTS, and accessory/peripheral functionality is solid.
The freeze seems to occur typically within 30min of boot and leads to the system being entirely unresponsive, requiring a hard reset via the power switch.
Given what I have access to, I'd say that maybe the 4.19 branch might be safer for this vintage hardware, given my issues with 5.6 currently.
