Hi, Realistically, the only thing that fits the interests of Fedora packagers, the cadence and interdependencies of the projects Fedora ships, is a form of rolling release. We are not a Microsoft that can tell its software groups “from now on you release with this cadence and support for this period” (and Microsoft gave up on that approach too). Hell Fedora cadencing was designed around the stated needs of the GNOME project, RH employs key GNOME devs, and GNOME requires releng exemptions for pretty much every Fedora release. That tells loads about the utter lack of respect upstreams have for Fedora cadencing attempts. Rings have always been an unicorn concept, we can’t even manage to keep our comps up to date for christsakes, any solution that posits a perfect package classification and breakup in modules or rings, and is maintained long term, is utterly utopic except for very small tightly controlled parts of the distribution. And don’t forget rings/modules add a version/time axis that is not required in comps. So the basic question is how to conciliate a rolling release with the needs of hardware sellers. I'd say that requires: * releasing initial installation states one or several times a year (1, 2, 3, or 4). Anything exposed in the official installer is part of this state. Anything added post-install or some other way does not get a Fedora commitment. * committing to making unattended full upgrades work from any intermediary state, more recent than the last Nth installation state, to the most recent installation state * reboots in upgrade environments are permitted, as long as those envs do not require human intervention * requiring users to blow up their disk with a new clean install because we don’t want to automate part of the upgrade is not permitted * that means testing to death upgrade paths from any state between n-1 and n to the initial-n state for every n value, and making sure the resulting initial-n is consistent with the initial-n values taken into account in the rest of the testing * that means testing to death any N-1 chain of jumps from initial-n to initial-n+1 * committing to making unattended point upgrades work from any state past the latest installation state to the current upgrade tip * committing that any hardware combo, that works in the Yth installation state, will still work at least till the Y+Z state, unless stated otherwise (and yes that requires identifying bad hardware that will stop being supported during the Z-step era, and defining at Y release time the free memory/disk/cpu margins that need to be taken for Z-step to be viable, and checking those in the installer) * that effectively means: * the only supported state is the current upgrade tip, * you have an N-era window where upgrades to the current tip are supported baring hardware problems * you have a Z-era window where upgrades to the current tip should not require hardware changes * any software state older than the latest installation state may require long reboots in automated upgrade environments * and because all this is too restrictive to some, and mightily hard to do without any early bird testing, you add a dev mode that unlocks early access to rawhide-style packages and installation options that may not work for N/Z windows. In dev mode there are no commitment to length of hardware support, and the only supported upgrade paths are point upgrades within the current upgrade cycle. That gives packagers two package streams to care about, devel and stable, which is pretty much what a lot of them do today. And that only answers the “how to get more users” question. The “how to get more packagers” question requires investing heavily in rpm and buildsys tech to automate aggressively all the steps that should not require manual packager processing, but do today. ie have people look at guidelines/review/updates, and ask themselves systematically “is there any part of the work the packager is doing that does not absolutely require human brains and could be automated one way or another”. And then make this automation happen. ie clean up the years of technical debt produced by “volunteer packager time is free, rhel packagers do what they’re ordered to, rpm is mature, make no radical changes”. rpm and deb “won”, no distro based on another tech succeeded in reaching mass appeal for years, that does not mean they are done. The software env changed a lot since rpm was designed. It needs a serious refresh, and not “this is how we’ve been doing things since forever”. Make it easier and cheaper for packagers to produce good packages, you'll have more packagers and a more attractive distro. Contrary to popular thinking making easier to produce garbage has little appeal except to people that just want to be rid of the deployment chore. Regards, -- Nicolas Mailhot _______________________________________________ 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
