On Mon, Oct 28, 2019 at 8:21 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > On Mon, Oct 28, 2019 at 2:16 PM Zbigniew Jędrzejewski-Szmek > <zbyszek@xxxxxxxxx> wrote: > > > > Hi, > > > > Thank you for this very useful summary. > > > > One general problem with the thinking behind this is that it applies much more > > to CentOS or RHEL than it does to Fedora. In particular: > > > users want a solid, stable, reliable, *unchanging* system. > > > > In that case, really, Fedora is not the answer. No matter how much I love > > Fedora, I know that it is never going to be most stable and reliable, and > > it is never going to be *unchanging*. > > > > There's a lot to unpack in your reply here, but ultimately most of it > seems to fall from this fundamental point. It's a logical fallacy > called "begging the question". The current state of Fedora is... > volatile. It's new, it's exciting and occasionally dangerous. But your > presumption here is that the danger should not be avoided. You're > saying "Fedora isn't stable therefore Fedora shouldn't be made more > stable" and effectively asserting that no one *else* would want it to > be more stable as well. I don't think we should "not want it to get more stable", and I don't think that was what Zbyszek meant with his reply. Still, I do not see how modules improve this situation for fedora. Fedora releases all reach EOL after 13 months, and will not get any more package updates. Separate module lifecycles won't change that (and as others have noted, this issue has also been considered and voted on by FESCo). On the other hand, the overlap between support cycles for fedora releases (either 7 or 13 months) and the release dates are *by design* aligned with other major software projects (GNOME, GCC, python, etc. which usually release new major versions either biannually or annually), so it makes it easier to ship major updates for these projects with new fedora releases, and there's no need for another layer of indirection with "phasing stuff in", because you only get major changes (such as new GCC) at distribution upgrade time, and never inbetween. And, since the fedora release cycle is so short compared to RHEL, separate module lifecycles 👏 just 👏 don't 👏 make 👏 sense 👏 here (because you can instead just align major updates with the next closest fedora release). Fabio > Yes, RHEL and CentOS have a particular business model that rides on > "nothing changes". Modularity offers us the chance to take some of our > more radical changes and phase them in, rather than push every user > onto them at an upgrade boundary. The assertion that users of Fedora > wouldn't be welcoming to "my apps are more stable but I still get the > latest kernel/platform stuff" is, in my opinion, incorrect. > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
