Kevin Fenzi wrote:
> I again completely disagree. There is no reason for weeks of breakage.
> Most of the issues that break composes are unannounced abi bumps where
> just rebuilding dependent packages fixes it. Or broken deps (likewise).
> Or mistakes made in kickstarts/comps. Or something that doesn't even
> run. What good does having everyone broken for weeks do?
There are several reasons why weeks of breakage are entirely reasonable for
a distribution under development:
1. A bump of a library to a new major version. It can take a few weeks for
dependent packages to be ported to the new version. But it is often worth
waiting rather than introducing a compatibility library with all the mess
that comes with it. (Of course, that does not hold for a library like Qt
where getting everything ported to the new version is not realistic even in
a couple weeks. Those are the cases where a compatibility library is needed
basically forever. But there are libraries where it makes sense to just port
everything.) The workflow would be to just bump the library to the new
version in Rawhide immediately and then let dependent packages get fixed
over time as their upstreams, Fedora packagers, or other distros' packagers
port them.
2. Vacation. The maintainer of the dependent package may be on vacation (or
even just busy with paid work, in case of volunteers) and therefore unable
to fix their package immediately. So you may have to wait a few weeks for
the broken dependency to get fixed if a simple rebuild is not enough.
This has all worked just fine in the past, before it was decided to make
basically every single broken dependency fail the entire Rawhide compose.
Soname bumps did not even have to be announced, they would get announced by
the broken dependency report within less than 24 hours anyway, and then
eventually fixed (without somebody unrealistically expecting maintainers to
fix the broken dependency in less than 24 hours to make the next compose
succeed, which is just plain impossible for the average volunteer packager,
especially if source code changes are needed).
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
