Vít Ondruch wrote:
Speaking of that, it seems that the Rawhide compose failed yesterday
due
to some KDE/QT soname bump:
[actually a typo in a Requires, as was already pointed
out]
Well, the real issue is that the entire Rawhide compose fails just because
one release-blocking deliverable failed to compose. In this case, it was the
KDE Spin, but it has been happening with any other release-blocking
deliverable, e.g., Atomic ostree composes.
Why can we not just deliver the parts that succeeded and keep the last
working version of the deliverables that failed to compose this time? In
other words, why can we not just upload the 20180228 compose and keep the
20180227 or whatever KDE ISO that last built? Why does it have to be all or
nothing?
Kevin Kofler