On Wednesday, November 14, 2018, 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.
The kernel is actually transparent to most users. Userspace ABI is guaranteed by upstream. So as long as kernel upgrades do not break users won't see much of a difference.
The only two exceptions are:
1) Out of tree driver users
2) People buying new hardware
For 1) kernel upgrades might be a problem if there driver is not updated fast enough
For 2) not having the upgrades is a problem because they would have to wait months before they can use their new hardware.
So ignoring case 1) it would be indeed "business as usual"
(Assuming upgrades do not break the system but that's what testing is for).
_______________________________________________ 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
