7:23 p.m.
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,
--
Michel Alexandre Salim
profile: https://keyoxide.org/michel@michel-slm.name
1:22 a.m.
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.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
11:39 a.m.
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,
--
Michel Alexandre Salim
profile: https://keyoxide.org/michel@michel-slm.name
1126
days inactive
1126
days old
2 comments
2 participants
participants (2)
-
Adam Williamson -
Michel Alexandre Salim