On Fri, 2020-08-28 at 16:59 -0700, Adam Williamson wrote: > On Fri, 2020-08-21 at 17:11 -0700, Adam Williamson wrote: > > Hi folks! > > > > So at this week's blocker review meeting, the fact that we don't have > > explicit networking requirements in the release criteria really started > > to bite us. In the past we have squeezed networking-related issues in > > under other criteria, but for some issues that's really difficult, > > notably VPN issues. So, we agreed we should draft some explicit > > networking criteria. > > Update: here's a second draft with feedback so far incorporated, thanks > to everyone. Still mulling over whether/how to split it more across > milestones. > > === Network requirements === > > Each of these requirements apply to both installer and installed system > environments. For any given installer environment, the 'default network > configuration tools' are considered to be those the installer documents > as supported ways to configure networking (e.g. for anaconda-based > environments, configuration via kernel command line options, a > kickstart, or interactively in anaconda itself are included). > > ==== Basic networking ==== > > It must be possible to establish both IPv4 and IPv6 network connections > using both typical router-provided addressing systems (e.g. DHCP on > IPv4 or SLAAC or IPv6) and static addressing. The default network > configuration tools for the console, for release-blocking desktops and > for installer environments must work well enough to allow typical > network connection configuration operations without major workarounds. > Standard network functions such as address resolution and connections > with common protocols such as ping, HTTP and ssh must work as expected. > > Footnote titled "Supported hardware": Supported network hardware is > hardware for which the Fedora kernel includes drivers and, where > necessary, for which a firmware package is available. If support for a > commonly-used piece or type of network hardware that would usually be > present is omitted, that may constitute a violation of this criterion, > after consideration of the [[Blocker_Bug_FAQ|hardware-dependent- > issues|normal factors for hardware-dependent issues]]. Similarly, > violations of this criteria that are hardware or configuration > dependent are, as usual, subject to consideration of those factors when > determining whether they are release-blocking > > ==== VPN connections ==== > > 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. > > 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, uh, we sorta forgot about this. Kamil approved this draft, but nobody else gave any feedback on it. This topic is still relevant and we have a proposed VPN blocker today, so...any more feedback on this draft? -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net _______________________________________________ kde mailing list -- kde@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kde-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/kde@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
