On Fri, Jan 10, 2020 at 09:18:35PM +0100, Nicolas Mailhot via devel wrote: > 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 I don't quite see how it conflicts with it either. You may end up having foo-1.0-42 in copr and foo-1.0-32 in koji which would lead to a foo-1.0-32 (or -39) at the next build, but I'm not seeing how it's a problem per say. Could you give a more concrete example? Thanks, Pierre _______________________________________________ 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