We, as a distro, just take a different approach. To be bleeding edge requires to have releases often.
That allow us to manage changes like GCC, OpenSSL and so on quickly. Struggling with upstream who don't adapt, can't adapt or don't want to adapt at the same speed. (And OpenSSL patch isn't something you'd want to write for serveral pojects you maintain ...) That is what make us different distro with its own user base. Want the very same but LTS system? try CentOS. Or RHEL. -- Speaking for myslef, the trouble is to keep up with the system wide changes even as a maintainer. The MariaDB package for example: In just last two years it went though 4 major releases - from 10.0 to 10.3. I put a big effort into dividing server and client part, changing packages layout and build dependency tree (for packages which need MariaDB). MariaDB also re-writtent the whole client library, huge change again. Than OpenSSL, new GCC, python 2 removal ... With so much changing, imagine the anguish of upgrades. Last half a year I tried to make COPR repositories for each major release (10.1-10.3) for every Fedora version (F27+). Worked well with "15 minutes of best effort" rule. Not sure if anybody used it though. Now I can slowly abadon the COPR thanks to modules which does the trick. However all of the problems remained, while I should put more energy and time into it. * Rebuild 10.1 with new OpenSSL? don't think so ... * Change package layout to undo some changes in releases that don support it? not compatible with the rest of the OS ... * Use release with old client library in Fedora version adjusted to new one? breaks literaly everything ... It's like "give me another folk working full time on it and I still don't believe we could solve all of this". What I wanted to express by this message is the fact, prolonging software support time in Fedora means *a lot* of low-level work TBD. I can maintain it either "bleeding edge style", geting users new features literally ASAP, or "LTS style" defend the database from any update to not break anything, bugfix and security fix only. (I'm doing it for RHEL after all). But not both. That would require wide matrix of versions adapted to every change, update and feature or not adapted at all (or just to some of them); depending on whether the specific user pick LTS version or evolving one. Looked for a solution for over a year. Not finding any. I keep saying RHEL & CentOS are our LTS versions. Wishing good luck to your search. -- Michal Schorm Associate Software Engineer Core Services - Databases Team Red Hat -- On Wed, Nov 14, 2018 at 12:37 AM Matthew Miller <mat...@fedoraproject.org> 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 > <mat...@fedoraproject.org> > Fedora Project Leader > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
