On Wed, 2022-09-07 at 17:47 +0000, Maxwell G via devel wrote: > I think this is a bad idea. It's quite hostile to packagers. It will > break rawhide for months and make it very difficult to stabilize the > distro before the beta freeze or do any type of rebuild. It very well > may > affect other Changes. It will still cause untold problems even if you > revert it before the beta freeze. Please test this in COPR (as Miro > already said) or somewhere else instead of destabilizing the distro. > You > can analyze the COPR failures and report bugs just like the Python > SIG > does for new Python major versions. I have no stake in this but participated in the test day (I don't think anyone else did?) so I would like to give my 2 cents. First for the results. I only noticed two issues: RPM Fusion signing keys and libimobiledevice no longer pairing with phones. Both are "trivial" issues. The former is a quick fix, the latter the maintainer has been notified and has expressed interest in modifying the codebase to switching from SHA1 to something like SHA256. COPR also had issues but again, that was a quick fix. Secondly, I agree that it is hostile to packagers. I filed an issue and the packager was kind of blindsided by the proposal. I have no issue with the term jump scare because I think such a radical change does need to "scare" people otherwise complacency leads to people being slow to migrate (see Python 2 -> 3 and people forking 2, despite having over a decade to switch to 3 for example). So maybe such a big change should have more communication and emphasis. Now while I only found a few issues doing testing, I have no doubt other people will have more exotic setups like specific hardware, VPNs, third party repos, etc. where things will break. Although I should say that I did testing across a wide variety of software including Tor, git, SSH and so on so assuming a relatively vanilla setup, most people should be fine. Anyway I agree on paper about testing it on COPR to avoid affecting the main distro, but I think that something like this can only encourage people to fix (or drop) software if there is intentional breakage. _______________________________________________ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
