[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-test-list
Subject:    Re: Post-mortem: Preventing broken updates from being pushed out?
From:       Michel Alexandre Salim <michel () michel-slm ! name>
Date:       2021-03-31 16:39:06
Message-ID: 29995d2ba7af7a804daa92f5301536ee1eeab5ec.camel () michel-slm ! name
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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

["signature.asc" (application/pgp-signature)]
[Attachment #6 (text/plain)]

_______________________________________________
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-leave@lists.fedoraproject.org
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/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure


[prev in list] [next in list] [prev in thread] [next in thread]