Dear all,
Following up on a broken update that got pushed: https://bodhi.fedoraproject.org/updates/FEDORA-2021-d42d8643e4
(I'm not naming the package here, as my goal with this discussion is not to assign blame but to figure out if we can prevent similar issues from reoccuring)
Event timeline: - an update is created - one person upvoted it - someone noticed it is incomplete (because it relies on a separate update but was not pushed together -- previous iterations of the same update, done by a different user, normally bundle these two together). They left a comment but no negative karma - two more upvotes so the update got automatically pushed out - someone else finally provided negative karma but the package is already out
IIRC we are making progress towards making sure updates are installable , and block pushes to stable based on that - is that coming soon?
Also, this is the wiki page that describes how to provide feedback to updates: https://fedoraproject.org/wiki/QA:Update_feedback_guidelines (it's linked from https://fedoraproject.org/wiki/QA:Updates_Testing)
It does not seem to have been changed much recently (I fixed a typo, but the previous update is from 2016).
Should this be linked to from the Bodhi page and/or fedora-easy-karma, or a succint summary be shown on the web UI and the CLI tool?
After browsing the page, it seems that it is slightly biased in favor of upvoting and/or leaving neutral feedback -- perhaps the use cases for providing negative feedback could be made more prominent (e.g. "negative karma will disable automatic push. If you think the update might break, do not hesitate to use this - you can always change your feedback later if you were mistaken".)
Best regards,
On Tue, 2021-03-30 at 17:23 -0700, Michel Alexandre Salim wrote:
Dear all,
Following up on a broken update that got pushed: https://bodhi.fedoraproject.org/updates/FEDORA-2021-d42d8643e4
(I'm not naming the package here, as my goal with this discussion is not to assign blame but to figure out if we can prevent similar issues from reoccuring)
Event timeline:
- an update is created
- one person upvoted it
- someone noticed it is incomplete (because it relies on a separate
update but was not pushed together -- previous iterations of the same update, done by a different user, normally bundle these two together). They left a comment but no negative karma
I didn't leave negative karma because it wouldn't necessarily help; it might just mean the *other* update got pushed stable first and that might still cause problems. I could've nerfed them both, but I figured I'd trust the maintainer to make sure they'd go stable together.
The maintainer did try to prevent the same thing happening to F32, but ran into issues navigating Bodhi. Bob, for future reference, the standard workaround for the case you ran into is just to bump and rebuild one of the packages with no changes. Then you can obsolete the update for the lower versioned build, and edit the higher versioned build into the update for the other package.
- two more upvotes so the update got automatically pushed out
- someone else finally provided negative karma but the package is
already out
IIRC we are making progress towards making sure updates are installable , and block pushes to stable based on that - is that coming soon?
It will happen whenever a new Bodhi release is made and deployed to stable.
On Tue, 2021-03-30 at 23:22 -0700, Adam Williamson wrote:
On Tue, 2021-03-30 at 17:23 -0700, Michel Alexandre Salim wrote:
Dear all,
Following up on a broken update that got pushed: https://bodhi.fedoraproject.org/updates/FEDORA-2021-d42d8643e4
(I'm not naming the package here, as my goal with this discussion is not to assign blame but to figure out if we can prevent similar issues from reoccuring)
Event timeline:
- an update is created
- one person upvoted it
- someone noticed it is incomplete (because it relies on a separate
update but was not pushed together -- previous iterations of the same update, done by a different user, normally bundle these two together). They left a comment but no negative karma
I didn't leave negative karma because it wouldn't necessarily help; it might just mean the *other* update got pushed stable first and that might still cause problems. I could've nerfed them both, but I figured I'd trust the maintainer to make sure they'd go stable together.
Yeah, the other update would have to be nuked to (or upvoted)
The maintainer did try to prevent the same thing happening to F32, but ran into issues navigating Bodhi.
Right, saw the F32 update unpushed.
- two more upvotes so the update got automatically pushed out
- someone else finally provided negative karma but the package is
already out
Ah, so of course this is how it happened. People testing had both test updates but somehow one was upvoted more than the other.
IIRC we are making progress towards making sure updates are installable , and block pushes to stable based on that - is that coming soon?
It will happen whenever a new Bodhi release is made and deployed to stable.
Exciting!
Another way this could be avoided in the future is if we encourage people to use side tags more? (Now that it works everywhere - even for EPEL, IIRC). I wonder if informing people about side tags when they try to make a buildroot override would help.
When using a side tag, Bodhi's web UI would helpfully populate the update with all the packages in that side tag. And if you miss a package and build it later into the same side tag, editing the update and refreshing would pick up the new packages.
Best regards,
-
Adam Williamson -
Michel Alexandre Salim