Bug details: ** https://bugzilla.redhat.com/show_bug.cgi?id=2006393 ** Information from BlockerBugs App:
Commented but haven't voted yet: catanzaro
The votes have been last counted at 2021-10-04 18:09 UTC and the last processed comment was #comment-754621
To learn how to vote, see: https://pagure.io/fedora-qa/blocker-review A quick example: BetaBlocker +1 (where the tracker name is one of BetaBlocker/FinalBlocker/BetaFE/FinalFE/0Day/PreviousRelease and the vote is one of +1/0/-1)
BetaBlocker +1
BetaBlocker
FinalBlocker
BetaFE
FinalFE
0Day
PreviousRelease
+1
0
-1
FinalBlocker +1
Discussed during the 2021-09-27 blocker review meeting: [0]
The decision to delay the classification of this as a blocker bug was made as this seems worrying, but we'd like to have a clearer idea of how commonly it is likely to happen in order to make a call on whether it should block the release.
[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-09-27/f35-blocker-review.2021-09-27-16.00.txt
Just want to add: we would not actually need to delay release for this if it is accepted blocker, because we can easily revert the DNS over TLS change if required. That's a one-line change in the systemd spec file.
Whatever the solution is would be fine for me. But 30 seconds delay may trigger some timeouts on services that depend on network services from remote services. I'm not sure if systemd dependencies really delays all such services long enough so that they work normally after the delay. For desktops and notebooks the user may be confused if there happens nothing for 30 seconds...
FinalBlocker +1 While I support more user privacy with this feature, I don't think it's important enough of a change to result in connect delay that's also non-obvious how to troubleshoot or revert
Metadata Update from @blockerbot: - Issue status updated to: Closed (was: Open)
Release F35 is no longer tracked by BlockerBugs, closing this ticket.
Log in to comment on this ticket.