Two questions for FESCo: - Should this bug be a Fedora 34 release blocking bug? - Should it block the beta or final milestone?
The simplest complete explanation is provided by @catanzaro in comment 7. But the scope of the problem is nebulous. It depends on the domain being looked up, what the CNAME record is, and whether/how its contents are being used, and on the environment; e.g. flatpaks are having a higher resolve failure rate. https://bugzilla.redhat.com/show_bug.cgi?id=1933433#c7
Perhaps the closets criterion that applies:
A bug in a Critical Path package that: * Cannot be fixed with a future stable update * Has a severity rating of high or greater and no reasonable workaround
However, it can be fixed with a future stable update, so this doesn't apply.
This is a sufficiently and urgently bad bug it needs to be fixed before final release. And possibly it should be fixed for beta release, on the basis that not doing so will limit (and likely confuse) beta testing.
So, I understand correctly that this happens with all CNAME records?
+1 to make this a beta blocker if that's the case.
Also, I'd be happy to introduce a "if the computer is physically able to connect to the the internet, internet must work" criterion.
Metadata Update from @ngompa: - Issue tagged with: meeting
+1 to make beta blocker
Not all CNAME records are affected. I'm unable to discern a pattern that results in failure, or the scope. What if 99% of the internet works with regular Firefox, but 50% with flatpaks? My sample size is too small though.
redhat.com, apple.com, microsoft.com, bbc.com, ebay.com, hulu.com, msn.com, msnbc.com, live.com, netflix.com, amazon.com, naver.com, nbc.com, xfinity.com - are affected and name resolution fails in both Firefox and Ungoogled Chromium flatpaks; yet I can reach all but netflix with regularly packaged Firefox. If the pattern is containerized applications, this could affect podman and nspawn containers, I haven't tested that at all.
+1 to make beta blocker (Though I don't think FESCo needs to be involved in this. Just the normal process in QA should be enough.)
+1 for beta blocker
Metadata Update from @sgallagh: - Issue tagged with: fast track
(Though I don't think FESCo needs to be involved in this. Just the normal process in QA should be enough.)
This was forwarded from that process because there's no specific criterion violated here, but they feel it's likely important enough to justify a FESCo blocker. Given that we're already in Beta Freeze, I proposed this also for the Fast Track process, so we don't draw this ticket out.
Metadata Update from @sgallagh: - Issue untagged with: fast track
ack fast track
This was discussed during today's FESCo meeting: APPROVED (+6, 0, 0) with the caveat that "if the scope is really small or something we can revisit next week."
Metadata Update from @zbyszek: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Metadata Update from @zbyszek: - Issue untagged with: fast track, meeting
Login to comment on this ticket.