Dne 16. 11. 18 v 0:54 Jason Tibbitts napsal(a): >>>>>> "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. Nice summary. > > 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. This last paragraph you could already apply to EPEL and this is specifically reason why I don't bother to maintain anything in EPEL. Vít _______________________________________________ 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
