I have a number of qpid packages promoted to "stable" that depend on qpid-proton-0.26.0-1.f28. However, someone blocked this package from being promoted, and as a result, updated qpid packages cannot be installed. We need to either: - Push qpid-proton-0.26.0-1.f28 to "stable" ASAP, or - Remove updated qpid packages from Fedora 28 I am not able to do either action, so I need rel eng advise/assistance on how to resolve this issue. Also see https://bodhi.fedoraproject.org/updates/FEDORA-2019-6b8b896b65 for reasons why this package was blocked. -- Regards, Irina.
On Wed, 2019-02-27 at 15:35 -0500, Irina Boverman wrote:
I have a number of qpid packages promoted to "stable" that depend on qpid-proton-0.26.0-1.f28. However, someone blocked this package from being promoted, and as a result, updated qpid packages cannot be installed. We need to either:
- Push qpid-proton-0.26.0-1.f28 to "stable" ASAP, or
- Remove updated qpid packages from Fedora 28
I am not able to do either action, so I need rel eng advise/assistance on how to resolve this issue. Also see https://bodhi.fedoraproject.org/updates/FEDORA-2019-6b8b896b65 for reasons why this package was blocked.
The builds that depended on qpid-proton-0.26.0-1.f28 should have been included in the same update as it so they could move through the lifecycle together, atomically. If this update had included them, they would not have been pushed stable without this build. In the future, I recommend putting builds that depend on each other in the same update to avoid this problem.
As for dealing with the problem now that they are pushed, it sounds like there are backwards incompatible changes in the proposed update. Is that correct? If so, the Fedora Updates Policy does say that we shouldn't push backwards incompatible changes to stable releases[0]. If not, it seems that three testers did think there were issues with the update, and Bodhi unpushed it automatically because it reached the negative karma threshold (-3).
If you think you have a case for why you should push a backwards incompatible update to a stable release, you can ask for an exception from FESCo to the policy[1]. If you decide to do that, please explain the situation so that FESCo understands the motivation behind the request.
If you decide to remove the other builds from Fedora 28, you might need to raise the epoch on those packages and make a new update to roll them back. Otherwise any users who may have updated to those packages will not get the rollback. Or perhaps someone else has a better solution than that…
[0] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#philosophy [1] https://pagure.io/fesco/new_issue
-
Irina Boverman -
Randy Barlow