On Wed, Nov 14, 2018 at 6:47 PM Laura Abbott <labbott@xxxxxxxxxx> wrote: > > On 11/14/18 5:29 AM, Matthew Miller wrote: > > On Wed, Nov 14, 2018 at 12:32:14PM +0100, Adam Samalik wrote: > >> Do we have any user data about what "stability" means to users and on what > >> different levels that can be achieved? Is it about app versions such as > >> MariaDB? is it about language runtime versions such as Node.js? is it about > >> things like glibc? or kernel? Or does it need to be the whole distro as we > >> have it today? > >> > >> In case we don't find a uniform solution that would fit all those cases (== > >> for the whole release as we know it today), focusing on those specific > >> levels (modules? rings?! ;) ) might help with different approaches could > >> help us at least a little bit. Well, considering there are some. > > > > I'm thinking mostly about a base platform. And even there, I think kernel > > versions and such can change -- we don't need a RHEL-style kernel ABI > > promise. We just need changes there to not break 1) the hardware it runs on > > and 2) the stuff on top. > > > > > > So it's business as usual for the kernel then :) > > More seriously, I do think we need to define what LTS actually means. > Especially for the kernel, there's already LTS defined upstream but that > may not align with what Fedora wants to do elsewhere. We may not want > a super strong RHEL ABI but actual LTS users may not want to deal with > other aspects of a kernel upgrade. Let's walk through this with some concrete examples. Assume for the moment the primary usecase is getting Fedora as a default option on laptop hardware from a variety of vendors, with a lifecycle of 36 months. What does that entail from a kernel perspective? I can see a few things to balance. a) You need a kernel that supports all the hardware on initial release. b) You need a kernel that continues to support all the hardware if it is rebased. c) You need a kernel that can support the hardware found in the next model after year 1 d) You need a kernel that can support the hardware found in the next model after year 2 e) (If we're ambitious), you need a kernel that can support the hardware for multiple vendor models across a 3 year timeframe. f) Most importantly, you need a kernel that provides a consistent interface to userspace for the full 36 months and does not regress support for any hardware At first glance, that looks like Fedora's existing kernel model could work find. Rebase, pick up support for new hardware, done. However, we know there are regressions in hardware support, and we also know that some laptop models are going to have hardware that doesn't have support in a released kernel version. So either you're looking at backporting to some existing kernel version in some fashion, or doing carefully tested rebases across laptop models, or a mix thereof. That catch, as I see it, with using an upstream LTS kernel is that it's great for stability and bugfixes. It's not great at meeting the "support new hardware" part. Which means backports. The longer that kernel is used, the further it drifts away from upstream, the harder the backports become. I think doing this for 36months is totally feasible, but we'd need to make sure we really look at it to understand what it would take. josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
