Thanks for starting this discussion, Matthew! A few notes: * My personal long-term dream is that all Fedora users are running Silverblue, we do great automated QA testing, and upgrading from one Fedora to the next is a non-event, and opt-out rather than opt-in, and long term support would not be needed. We aren't there yet. :-) * If we have a long-term support branch, the stuff that's in the default install / the stuff that would be in a Silverblue image - should be rebased very sparingly. I think we'd have to define this set - it's bigger than the current "critical path". * As we move higher up the stack, it's more reasonable for maintainers to take an approach of maintaining a single version across active Fedora branches - and we have various mechanism to make that easier: packages.cfg, module stream expansion, Flatpaks. * The kernel is a big question mark - our kernel maintenance strategy really *assumes* that we can aggressively rebase, but if the Fedora project is working with a hardware vendor, the kernel is the component that the hardware vendor is probably going to be squeamish about. Not sure what the solution here is - sync to a LTS kernel? Presumably part of Fedora working with hardware vendors would be figuring a good testing strategy so that updates get testing on the actual hardware before going out. * If we are offering a long term branch as a strategy to work with hardware vendors, what happens when users *choose* to upgrade to a newer stable Fedora? - Owen On Tue, Nov 13, 2018 at 6:37 PM Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > > > Hi everyone! Let's talk about something new and exciting. Since its > first release fifteen years ago, Fedora has had a 13-month lifecycle > (give or take). That works awesomely for many cases (like, hey, we're > all here), but not for everyone. Let's talk about how we might address > some of the users and use cases we're missing out on. > > When I talk to people about this, I often get "hey, you should do LTS > or go to rolling releases.” As I've said before, on the surface that's > a weird thing to say, since the actual user impact of those two > different things is mostly _opposite_. So, digging in, it often really > means "I don't want the pain and fear of big OS upgrades". > > We've addressed that in several ways: first, making upgrades better. > (Thanks everyone who has worked on that.) A Fedora release-to-release > update is normally not much more trouble than you might get some random > Tuesday with a rolling release. Second, we have some things like Fedora > Atomic Host and upcoming Fedora CoreOS and IoT which both implement a > rolling stream on top of the Fedora release base. And finally, there's > the coming-someday plans for gating Rawhide, making that a better > proposition for people who really want to live on the edge. > > 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. Second, there are people who really could be happily running > Fedora but since we don't check the tickbox, they don't even look at us > seriously. I'd love to change these things. To do that, we need > something that lasts for 36-48 months. > > So, what would this look like? I have some ideas, but, really, there > are many possibilities. That's what this thread is for. Let's figure it > out. How would we structure repositories? How would we make sure we're > not overworked? How would we balance this with getting people new stuff > fast as well? > > > > > -- > Matthew Miller > <mattdm@xxxxxxxxxxxxxxxxx> > Fedora Project Leader > _______________________________________________ > 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 _______________________________________________ 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
