Le vendredi 10 janvier 2020 à 20:53 +0100, Fabio Valentini a écrit : > > You can never expect our tooling to do "magic" (TM) and work "just > right", no matter which Versions and Releases and Epochs of packages > are available from third-party repos and coprs. Yes, sure, but the current way we manage releases accomodate those worklows. For example: 1. I hit a fontconfig bug while preparing the new font packaging guidelines, 2. Akira kindly fixed the problem upstream, https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/185 3. it was trivial to build a package matching the Fedora fontconfig with just the fix added in copr, without breaking the release thread https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/build/1126851/ (it exists just for me in my copre because general availability was not required to advance on the guidelines proposal; general availability would have required a push to rawhide and a support commitment by Akira) And, it will all converge once FPC finishes its review, Akira releases fontconfig upstream, and the result is rebuilt for Fedora. Had I waited for Akira to wrap up an upstream release and build the result rawhide- side the FPC submission would have been pushed back for months (and then it would have delayed other Fedora changes, it's a cascading effect). The non-linear progression permitted by current manual release setting allows parallelizing work and getting things done a lot faster within the project. I don’t see how to manage this with the autogeneration proposal Regards, -- Nicolas Mailhot _______________________________________________ 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
