>>>>> "MM" == Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> writes: MM> Let's talk about something new and exciting. I assume that you mean "very much not new and about as exciting as the fifteenth viewing of an episode of the Joy of Painting". I know it's been a while. Maybe it's been long enough that a significant number of the developers here don't remember it. I am pretty sure you were around, though, so I do hope you have some recollection of it. Put simply, Fedora has had this discussion before. A number of times. Going back to FC1 and what the release cycle would look like. At one point it was basically an endless thread that lasted the better part of a year. For the life of me I simply can't remember the various proposals called their releases, though. One example of what I'm talking about is https://kanarip.fedorapeople.org/Fedora%20Extended%20Lifecycle%20Support%20-%20The%20why,%20the%20what,%20the%20how%20and%20the%20who.pdf but that came after I stopped paying attention to this kind of thing. In the end the discussions I recall seemed to come down to a few basic things. 1) A lot of people would love to consume such a release. 2) Not nearly as many actual maintainers would want to do so. 3) At minimum, we need a kernel. Which means we need a kernel team. I doubt the current kernel team would be any more enthusiastic about either backporting everything, maintaining packages of the extended lifetime kernel packages (assuming those even line up with the release schedule) or pushing the current kernel back to the equivalent of... Fedora 25 or so. 4) Someone has to do release engineering. Even in the earlier days this was seen as something that wasn't going to happen. My recollection is that meaningful discussion usually stopped at the kernel issue. At one point we had some basic agreement that people who cared were welcome to push to old branches of things to keep them going, but that was back when we had per-branch ACLs. But that never happened, and as there was no effort to actually compose updates for those releases, it doesn't matter much anyway. And now we're bigger, and there are more big systems that would need maintenance. Oh, and we have a security team now; they'd have to deal with issues in those old releases. And more big package sets like Python and Node and Go and whatever, some of which amount to a larger number of packages than made up the entirety of one of the old Fedora releases. Hello, Python SIG? Good luck finally getting rid of python2. You get two more years of support backporting security fixes and you don't even get paid for it. And to add in an additional argument that we didn't have a decade ago: We're actually trying to evolve our packaging now. EPEL with it's "old RPM never changes" restriction is bad enough but fortunately limited in scope. Having years of Fedora releases that can never evolve but which still hold back progress in Rawhide is just too much. Really, this is what our downstream distributions RHEL and CentOS are for. That was the answer then and I don't see why it doesn't still apply. MM> How would we balance this with getting people new stuff fast as MM> well? Wait, what? Certainly you're not suggesting trying to do an extended lifecycle that also gets all the new stuff. That's seems like a contradiction in terms. - J< _______________________________________________ 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
