On Tue, Nov 13, 2018 at 4:37 PM Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> 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. 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. - Ken _______________________________________________ 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
