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