On Mon, Oct 28, 2019 at 03:56:11PM -0400, Stephen John Smoogen wrote: > I think the issue is that neither of you are defining what expected > lifespans of stability or what stability is. After that you can > disagree whether it is important or not to what you want to do... but > until then you are both talking past each other.
You are right. My statement was vague enough to be useless. Let me try again: I don't think Fedora is a good base to build or install packages that will not change for a long time, where long time is anything longer than one or two Fedora releases. And I do mean *packages*, not software in general. The ability to build software depends on the underlying kernel and glibc and compilers and libraries, and those remain broadly backwards compatible. But we change the way things are packaged and configured: new compilation flags, new security features, latest glibc and gcc, latest kernel, latest systemd, latest python, new CI checks, appdata, new version of cgroups or firewall implementation, etc. Those changes requires constant tweaks to packaging, but provide packages that improve over time. We are trying to add automation to packaging of python and rust and other upstream projects. This all means that even if a package from two years ago still builds or installs in Fedora, we most likely do not *want* it, because we require more from our packages, but also because have better ways to build packages. Stephen said: > 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. This is exactly the circle which I think we can't square. There is no "kernel/platform stuff" that we can keep updating while providing a uniform interface to higher layers or anything like that. Let me use an example: F32 will switch to python3.8. Many packages required fixes to work with python3.8. Python maintainers (and many other Fedora developers) worked with upstream projects, and many upstream projects made releases with patches either written by us or for us. This often coincided with dropping python2 support. At the same time, sphinx and pytest released new major versions. This means that Fedora pushed the whole ecosystem forward, but keeping packaging unchanged in F29 (python2 is still king), and F32 (python3.8 is required) is very hard. And anything which is closely dependent on python will require some small changes. For me, stability of the core to allow the same packages to be reused across versions is an anti-goal and something that shouldn't be promised. This might happen, but should not be constrained by what changes we can make. Instead, I want the distro to keep running forward as a whole, with the ability to coordinate changes to multiple projects and packages when the need arises and flexibility to change packaging standards and mechanisms and require rebuilds. The problem is completely different in RHEL/Centos because the cadence is much longer. I see how important it is for users there to gain access to alternative versions of packages. But in Fedora, such packages are always at most a few months away. So yeah, I do hope Fedora can be more stable (in the sense of a bug-free and smoothly upgrading system), but not stable (in the sense of unchanging). Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
