On Wed, Nov 14, 2018 at 11:11:59AM -0700, Ken Dreyer wrote:
On Tue, Nov 13, 2018 at 4:37 PM Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
> But there are some good cases for a longer lifecycle. For one thing,
> this has been a really big blocker for getting Fedora shipped on
> hardware.
This is an interesting topic to me because I recently toured the
System76 factory here in Denver. They are engineering their own
operating system (Pop!_OS) on top of Ubuntu, and I would love to see
Fedora become more viable as a base in these types of situations.
We have a lot of data stored in Bodhi. I've wondered about mining the
security update data in particular to discover:
A) How many security updates that we push that would have affected
older versions of Fedora, over time? In other words, based on the
Fedora 28 data, how many security updates does Fedora 27 lack 3 months
past its EOL? 6 months? 12 months? That would give a rough scope of
the security situation and level of effort.
The answer is "a lot". I don't think we have any hard numbers, but
see
https://pagure.io/fesco/issue/1935. Generally, it seems we can't
process the CVEs we get now.
"This result was limited to 1000 bugs." → that's just for CVEs.
B) Is it possible to "mock rebuild" those security
updates' SRPMs for
the EOL Fedora releases? How much harder does it get over time? This
could be a semi-automated way to experiment with extending the
lifecycle of older Fedoras.
Obviously this is not perfect, but I imagine that solely focusing on
security updates could help extend the lifecycle from 13 months to
maybe 25 months.
Zbyszek