[prev in list] [next in list] [prev in thread] [next in thread]
List: fedora-devel-list
Subject: Re: Fedora Lifecycles: imagine longer-term possibilities
From: drago01 <drago01 () gmail ! com>
Date: 2018-11-15 7:15:27
Message-ID: CAMqY-Fe6XFAQg0qRYVGjBh7OgZxhLzqSLiZKVVMKA6DbFMO+rg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wednesday, November 14, 2018, Laura Abbott <labbott@redhat.com> 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).
[Attachment #5 (text/html)]
<br><br>On Wednesday, November 14, 2018, Laura Abbott <<a \
href="mailto:labbott@redhat.com">labbott@redhat.com</a>> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">On 11/14/18 5:29 AM, Matthew Miller wrote:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> On Wed, Nov 14, 2018 at 12:32:14PM +0100, Adam Samalik \
wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"> Do we have any user data about what \
"stability" means to users and on what<br> different levels that can be \
achieved? Is it about app versions such as<br> MariaDB? is it about language runtime \
versions such as Node.js? is it about<br> things like glibc? or kernel? Or does it \
need to be the whole distro as we<br> have it today?<br>
<br>
In case we don't find a uniform solution that would fit all those cases (==<br>
for the whole release as we know it today), focusing on those specific<br>
levels (modules? rings?! ;) ) might help with different approaches could<br>
help us at least a little bit. Well, considering there are some.<br>
</blockquote>
<br>
I'm thinking mostly about a base platform. And even there, I think kernel<br>
versions and such can change -- we don't need a RHEL-style kernel ABI<br>
promise. We just need changes there to not break 1) the hardware it runs on<br>
and 2) the stuff on top.<br>
<br>
<br>
</blockquote>
<br>
So it's business as usual for the kernel then :)<br>
<br>
More seriously, I do think we need to define what LTS actually means.<br>
Especially for the kernel, there's already LTS defined upstream but that<br>
may not align with what Fedora wants to do elsewhere. We may not want<br>
a super strong RHEL ABI but actual LTS users may not want to deal with<br>
other aspects of a kernel upgrade.<br><br>
</blockquote><div><br></div><div>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.</div><div><br></div><div>The only two \
exceptions are:</div><div><br></div><div>1) Out of tree driver users</div><div>2) \
People buying new hardware</div><div><br></div><div>For 1) kernel upgrades might be a \
problem if there driver is not updated fast enough </div><div><br></div><div>For 2) \
not having the upgrades is a problem because they would have to wait months before \
they can use their new hardware.</div><div><br></div><div>So ignoring case 1) it \
would be indeed "business as usual"</div><div><br></div><div>(Assuming \
upgrades do not break the system but that's what testing is for). </div>
[Attachment #6 (text/plain)]
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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@lists.fedoraproject.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic