Re: Fedora Lifecycles: imagine longer-term possibilities

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux