Well, I have read tons of things, and only one thing bump in my head: "Ubuntu LTS"
I mean, it's a great idea, and a lot of people have asked about it in forums, reddit, twitter, fedoraforums and the list goes on. I thing that if someone can make it happens is the awesome Fedora Developers team, but actually my concern is in how to avoid the comparison, or being called copycats, or put in doubt both originality and innovation. I know is probably too early, but give it a thought from the point of view of the marketing: How we can advertise a product that others have? Br, El jue., 15 nov. 2018 a las 21:46, Jason Tibbitts (<ti...@math.uh.edu>) escribió: > >>>>> "MM" == Matthew Miller <mat...@fedoraproject.org> 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@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 > -- Eduard Lucena Móvil: +56962318010 GNU/Linux User #589060 Ubuntu User #8749 Fedora Marketing Representative
_______________________________________________ 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
