Oh hey, abuse of provenpackager. So much for caring about policy, eh? :)

As kindly as I can: absolutely not.

I fixed a security issue with an assigned CVE. I am not going to seek anyone's approval to fix publicly disclosed security issues. (The only thing you can possibly do is demand I leave it vulnerable, so again: absolutely not.)

As with all packages in Fedora, you are welcome to submit patches that change things to be more to your liking - but I'm obviously not going to accept those that reintroduce security bugs, so have fun fighting el7's C++ compiler...

I wasn't. I gently asked you to stop telling me how to do my job. Unlike your sarcasm, that's not rudeness.

Breaks non-latin characters and gfxterm. Must be unpushed.

Please don't tell me how to do my job, thanks.

As it is, there isn't enough information in your report for me to actually investigate.

Hi @thesourcehim, this is a CVE update I'd like to get to users. Could you file a bug with your use case that we can look into rather than blocking this update?

Yeah, delay on autopush is what I was imagining.

I hear what you're saying about quick +1s, but I don't get more than 3 karma basically ever - the fix for the update @kparal is lamenting as a huge problem to be avoided only got 4, so...

5.18.13-200.fc36.x86_64

Okay, that's a kernel version, not grub2 version or a grubby version.

dnf clean all --enablerepo=*

Not sure what this is for.

grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

This destroys the stub configuration at that location. The correct command is grub2-mkconfig -o /etc/grub2.cfg, but I don't know what you're doing that needs to run that, unless you're trying to test #2117817?

This only occurs if /etc/kernel/cmdline exists, sorry for not catching that earlier.

At the top of this update, I stated: "Note that if you have tested a recent grub2/grubby update, you will need to remove /etc/kernel/cmdline before testing this one.". This is why.

If, after removing /etc/kernel/cmdline and applying this update, what you're trying to do works, then I believe everything is working as expected.

@flawedlogic I'm not sure what you're trying to do (or test) or which file you're referring to.

@awee85 I appreciate your interest (and testing). People need to stop finding bugs in it first :)

More seriously, a higher karma threshold was requested by @kparal and while I still don't know how I feel about that in the general case, I do appreciate having issues like @bojan's caught before these fixes hit users. Right now, issues in these packages are only getting caught when I submit them to bodhi - there isn't this kind of testing for my rawhide builds - which also makes them take longer, unfortunately.

This update has been unpushed.

@ausil thanks - can you retest with -66 please?

https://bodhi.fedoraproject.org/updates/FEDORA-2022-a3480ad0d3 new update attempting to address these problems.

Hi bojan, pbrobinson - I don't have enough information for that feedback to be actionable. Maybe you could open bugzillas, or mention which existing ones apply?

One option I do want to draw your attention to in bodhi is "Require bugs", which "If checked, this will require that positive feedback be given on all associated bugs before the update can pass to stable. If your update has no associated bugs, this option has no effect.". We use this option (because it's default) - this means that the only reason the update advanced as quickly as it did was that someone asserted testing of the attached Windows bug. So the idea that Windows would somehow be more broken seems vanishingly unlikely to me.

Or they can be pushed faster, if the maintainer is certain and the feedback is great, but it should be a conscious decision, i.e. a manual push.

No, please do not inject more manual steps into our workflows. There are too many context switches already. If bodhi adds the ability to default to a minimum 24h in testing (for example), I would definitely consider enabling that. (I think it probably should be global, but now we're getting out of scope.)

In a few days, there will be some bug reports, if things break horribly.

And we get them, and fix them, as in this update :) Bugs will happen, no matter how much testing we throw at updates. That's just software.

Also, regarding karma feedback, it's a little misleading. It's true that overall we don't have enough testers providing karma (your examples, however, were from when Fedora 36 was pre-release, we have even fewer of them at that times).

I don't think so, because the same is true of released Fedoras. But the point is not to argue about specific updates: the point is that, as I think we both know, the amount of karma received is wildly variable and cannot be depended on. (You might recall the grub2 CVE update to post-release Fedora 35, where only you (thanks!) and one other person provided karma and it sat for the full 2 weeks.)

More generally, it seems to me that your issue is with the quality of feedback being provided by other testers on bodhi and the speed with which they provide it. The guidance for +1 is "Is the update generally functional?" - which I take to mean that the tester asserts that, according to their testing, they believe the package to function in an expected manner consistent with the release criteria. I am honestly not seeing a way it could mean anything else, nor can I vet the quality of testing based on the information they currently provide (and I don't think it's reasonable for me to do so).

No, not in the general case, but I will explain my thinking. Bodhi is also used for security updates, where, since Fedora has no embargoed build process, speed is also a concern. Generally bodhi updates sit for much longer: frankly, I think having a bug that people cared about caused this one to receive more attention during testing. For instance, see this previous Fedora 36 grub update that went stable due to time not karma, or this earlier grub2 update for Fedora 36 that went stable after 2 weeks and no karma at all, etc., etc.. The list goes on, but point is that it's normal to receive little if any karma, even on the bootloader.

As for "what if it breaks even more?"... well, that's tricky, isn't it? It's a risk on all changes, sure, but the reverse is also true. Especially in this case, where there's a high-profile bug we want fixed: which means that the longer we leave it unfixed, the longer ostree is broken and we can't chainload windows right. To be specific, adding to the profile of this bug is that it is believed to block a release criteria and was proposed as both Prioritized and Common. Obviously some people care a lot about getting this fixed quickly.

I hear your concerns about not wanting to play fast and loose with critpath packages. So far, I'm not aware of problems that have stemmed from the standard +3/2 weeks policy, though if that does start causing issues we can of course revisit. Given most of my updates are going to time already, I don't see the value in raising to 10-15 as you suggest: this seems like it would guarantee they all go to time.

pjones spoke to that in https://bugzilla.redhat.com/show_bug.cgi?id=1955416#c88:

f35, f36, and rawhide eventually all need the same build, so test with the one above, and I'll work with rel-eng on tagging when it's okay to do so.

Since this update is now stable, I imagine it will shortly be okay to do so if it's not already.

Boots my SB vm.