On Mon, 2022-06-13 at 03:09 +0200, Kevin Kofler via devel wrote: > Adam Williamson wrote: > > Using the default network configuration tools for the console and for > > release-blocking desktops, it must be possible to establish a working > > connection to common OpenVPN, openconnect-supported and vpnc-supported > > VPN servers with typical configurations. > > Is "common" a rationale or a restriction? I.e., are all VPN types supported > by OpenConnect automatically "common", or which ones are "common"? It's a restriction. I'm not sure we would actually want to block the release on absolutely every possible openconnect VPN configuration. I admit I'm not an expert on the details, which is why it's worded quite generally. If someone wants to try and write something more specific, that'd be great. > > (In particular, I care about ocserv.) DDG tells me that's an open source server intended to be compatible with openconnect clients, i.e. an open source alternative to the proprietary CISCO server. So in the case we had a bug that broke connections to ocserv servers but not connections to the official Cisco server, we'd have to try and figure out how widely ocserv is used, I guess. > > > Footnote titled "Supported servers and configurations": As there are > > many different VPN server applications and configurations, blocker > > reviewers must use their best judgment in determining whether > > violations of this criterion are likely to be encountered commonly > > enough to block a release, and if so, at which milestone. As a general > > principle, the more people are likely to use affected servers and the > > less complicated the configuration required to hit the bug, the more > > likely it is to be a blocker. > > So it is a case by case decision by the reviewer? Then why bother having > written criteria at all? To at least clearly establish that bugs in this area *can* be blockers. Without this addition, on a strict reading of the criteria you have to be fairly creative to interpret them as allowing *any* kind of bug in VPN support to be release-blocking. And they really don't say anything specific about networking at all. In the past we've accepted complete networking fails as violations of things like the "browser must work" or "updates must work" criteria, but that feels quite a lot like a hack, and it's harder to keep a straight face when applying a hack like that to a bug which isn't as bad as "networking is completely busted for a lot of people". As the guy who writes most of the criteria, what I'd really like to have is completely objective rules that remove the need for any kind of subjective evaluation. But experience suggests this is really hard to do without painting yourself into all sorts of weird corners. It's very hard (for me, anyway) to imagine every possible proposed blocker related to VPN or network functionality in general and, ahead of time, write rules that decide which ones are and are not blockers. But there's clearly a feeling that, in general, we should not be shipping Fedora with major bugs in VPN support. So, this is my best effort. As I wrote above, if you or anyone else can draft some sufficiently detailed and comprehensive rules for this area which remove or reduce the need for subjective case-by-case evaluations, that'd be fantastic and I'd be all in favour. But this was as specific as I could get myself. It seems like in some areas we just have to go with this "criterion establishes broad principles / specific issues are evaluated case-by-case" approach. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
