|
On 2018-11-13 3:36 p.m., Matthew Miller 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? > > > > The biggest issues are proper documentations and manpower. Before planning a long term release, improving the existing infrastructure accepting new contributors and active maintenance of packages (say adding a co-maintainer)with a guideline easy to read and understand should be the main priority. Case in the point with the current wiki hard to navigate when it comes to look at the information leading to an outdated version. Additionally, have more polishing on the entire Fedora operating system is a bonus i.e. presentation (looking at the marketing department, one of the strong point from Ubuntu) and solid foundation. Luya |
Attachment:
0x5E528174D8A2609A.asc
Description: application/pgp-keys
_______________________________________________ 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
