Zbigniew Jędrzejewski-Szmek wrote: > So... building multilib packages is still very much supported. You cannot > *run* a pure-i686 environment, but you can 32 bit development. You have to configure a slow, non-mirrored repository for that instead of just using the same mirrored URL pattern (with $basearch substituted automatically) as for the still fully supported architectures. And there is no real technical reason to do that, the only goal was to deliberately inconvenience users attempting to use the software. >> * the insane proposal to require AVX2 for x86_64, which has thankfully >> not been implemented so far, but against which we will likely have to >> fight again and again during the next few years, > > This proposal was rejected very forcefully. fedora-devel was unanimous > with >100 messages, which I have never seen apart from that once case. > If it get's proposed again, you can expect the same result. I have seen several features with similarly overwhelmingly negative fedora-devel feedback that were waved through by FESCo anyway. (See, e.g., Modularity, where from the beginning, I and others had pointed out the provably unsolvable flaws in the core design axioms, which, very unsurprisingly, materialized exactly as predicted, see https://communityblog.fedoraproject.org/modularity-vs-libgit/ . All this did not prevent the feature from getting approved and implemented.) > Well, yes. Unmaintained packages are retired. Sorry, but it's either that > or development of new things in Fedora stops, because every change is > hamstrung by uninstallable and unbuildable packages. We just can't have > packages with no maintainers. Most packages with no maintainers actually still just work (without even a rebuild). Some require a trivial rebuild. Only a handful are actually broken, and those are reasonable candidates for a removal. But removing working packages only for the lack of a maintainer serves no purpose and is a pure disservice to the users of the package. There is often no reasonable alternative tool for the purpose. So what are the users of the removed package supposed to do? > Those removals are not quick: FTBFS packages are retired after *months*, > orphaning usually only happens when there are long-standing unresolved > bugs. In most cases, the package is bitrotting for multiple releases > before any removal happens. Orphaning usually happens because the maintainer explicitly orphans the package. The policies then leave only 6 weeks for the package to get adopted before it will get retired! That is not "long-standing" at all. And if an otherwise maintained package FTBFS, if it does not actually need any change, I don't see how this is even an issue at all. > That's very much unfair. The python team has put an _insane_ amount of > work into telling everyone about the transition, planning all the > steps, filing bugs, retiring leaf packages first, asking for feedback, > fixing bugs, etc, etc, etc. "Agressive" would be all python2 packages > were simply dropped after F32 branching. If only they had instead put such an "_insane_ amount of work" into actually maintaining, and committing to maintain for at least 5 to 10 more years, the python2 compatibility package, which is actually not work-intensive at all (just backport security fixes from Python 3 as they happen, which they'll likely have to do for RHEL anyway). Instead, a lot of time was wasted spamming everyone about the impending scorched earth "transition", quickly getting an unreasonable "plan" with a totally insufficient transition period rubber-stamped by FESCo, dropping random leaf packages they hoped nobody would notice (when actually, those leaf packages are the whole reason we need the compatibility stack to begin with; the leaf packages are what the users actually use and need!), ignoring all feedback (at least all that did not just blindly agree with their nonsense "plan"), "fixing" "bugs" (typically just removing Python 2 support from random packages in the hope nobody would notice), etc., etc., etc. See qt (4) and kdelibs (4), and qt3 and kdelibs3, for how compatibility should work. > So sorry, but you can't expect every obsolete hardware technology and > software stack from previous decade gets to hold everyone else hostage. Compatibility is not "holding" anyone "hostage". Nobody is forced to use old hardware or compatibility libraries. The unilateral removal of such "obsolete" technologies is what is holding users hostage. Kevin Kofler _______________________________________________ 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
