hi all,
the critpath update for httpd-2.4.53.fc34 is stuck in updates-testing. bodhi reports a pending test for this package.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-21264ec6db
I can confirm, that i rolled out this update on my web->cluster<- and pages do still work. httpd test suite passed (php, ssl, static ). Pls push it to stable.
best regards, Marius Schwarz
On Thu, 2022-03-24 at 18:46 +0100, Marius Schwarz wrote:
hi all,
the critpath update for httpd-2.4.53.fc34 is stuck in updates-testing. bodhi reports a pending test for this package.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-21264ec6db
I can confirm, that i rolled out this update on my web->cluster<- and pages do still work. httpd test suite passed (php, ssl, static ). Pls push it to stable.
It's been stuck for five days, not a week. After a week it will be pushed automatically, because that's what the maintainer set. Nothing to do with automated testing is holding it up; its gating status is passed. It just hasn't been pushed yet because it didn't get enough karma to be auto-pushed.
It seems just not a lot of people run N-2 with updates-testing enabled, unfortunately. We always get much more karma for N-1 than for N-2.
Am 24.03.22 um 18:53 schrieb Adam Williamson:
It's been stuck for five days, not a week. After a week it will be
It's a crit update with security implications and needs that push to stable, when the basis tests have been finished ( 6 days ago btw ) . I know it had one automated test failed, but thats AFAICS just the filesize check from jenkins.
Can someone now pls push it?
Best regards, Marius Schwarz
On Thu, 2022-03-24 at 20:23 +0100, Marius Schwarz wrote:
Am 24.03.22 um 18:53 schrieb Adam Williamson:
It's been stuck for five days, not a week. After a week it will be
It's a crit update with security implications and needs that push to stable, when the basis tests have been finished ( 6 days ago btw ) . I know it had one automated test failed, but thats AFAICS just the filesize check from jenkins.
Can someone now pls push it?
In point of fact, no. Nobody can. It needs either more positive karma or two more days in testing, under the policy. As I said, the automated test failure is irrelevant to this.
Adam Williamson wrote:
In point of fact, no. Nobody can. It needs either more positive karma or two more days in testing, under the policy. As I said, the automated test failure is irrelevant to this.
Actually, this is not a critical path package (or the minimum timeout would be 2 weeks, not 1), so the stable threshold could be lowered to 1, then the update can be pushed.
In fact, I think I could even technically do that (both lower the threshold and queue the package for stable) as a provenpackager, but I do not want to overrule the maintainer.
That said, I am still not convinced that it is a good idea that critical security updates (and other urgent updates, such as, e.g., regression fixes) cannot be pushed directly to stable without any karma requirement at all as was the case a (sadly) long time ago. (I have been trying without success to get this decision overturned ever since.)
Kevin Kofler
On Fri, 2022-03-25 at 02:18 +0100, Kevin Kofler via devel wrote:
Adam Williamson wrote:
In point of fact, no. Nobody can. It needs either more positive karma or two more days in testing, under the policy. As I said, the automated test failure is irrelevant to this.
Actually, this is not a critical path package (or the minimum timeout would be 2 weeks, not 1), so the stable threshold could be lowered to 1, then the update can be pushed.
Oh, I was just assuming it was. Yes, if it's not critpath, it can be submitted by the maintainer or a proven packager once it has 1 karma. (You don't actually need to edit the threshold, you can just use the bodhi CLI).
On Thu, Mar 24, 2022 at 06:51:06PM -0700, Adam Williamson wrote:
Oh, I was just assuming it was. Yes, if it's not critpath, it can be submitted by the maintainer or a proven packager once it has 1 karma. (You don't actually need to edit the threshold, you can just use the bodhi CLI).
Although this is not necessarily automatically better. Fast security updates are important, obviously, but untested security updates? Not so much. It doesn't take very much _at all_ for people who rely on critical fixes for N-2 to confirm that the update addresses the problem without regressions. Surely there are more then _three_ people who care about this.
On 3/24/22 21:18, Kevin Kofler via devel wrote:
Adam Williamson wrote:
In point of fact, no. Nobody can. It needs either more positive karma or two more days in testing, under the policy. As I said, the automated test failure is irrelevant to this.
Actually, this is not a critical path package (or the minimum timeout would be 2 weeks, not 1), so the stable threshold could be lowered to 1, then the update can be pushed.
In fact, I think I could even technically do that (both lower the threshold and queue the package for stable) as a provenpackager, but I do not want to overrule the maintainer.
That said, I am still not convinced that it is a good idea that critical security updates (and other urgent updates, such as, e.g., regression fixes) cannot be pushed directly to stable without any karma requirement at all as was the case a (sadly) long time ago. (I have been trying without success to get this decision overturned ever since.)
Kevin Kofler
YES PLEASE!!!! Right now I to use the following ugly workaround:
dnf --best --refresh --security --enablerepo=updates-testing upgrade && dnf --best upgrade
I’d much rather be able to do just `dnf --best --refresh upgrade`.