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.
This turns out to be a big area and quite hard to cover (who'd've thought!), but here is at least a first draft for us to start from. My proposal would be to add this to the Basic criteria. I have left out some wikitext stuff from the proposal for clarity; I'd add it back in on actually applying the proposed changes. It's just formatting stuff, nothing that'd change the meaning. Anyone have thoughts, complaints, alternative approaches, supplements? Thanks!
=== 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 DHCP and static addressing. The default network configuration tools for the console and for release-blocking desktops 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 VNC servers with typical configurations.
Footnote title "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.
On Sat, Aug 22, 2020 at 12:12 AM Adam Williamson adamwill@fedoraproject.org wrote:
It must be possible to establish both IPv4 and IPv6 network connections using DHCP and static addressing.
For IPV6, SLAAC is more common than DHCP(v6) (especially) in the consumer space. I would like to see a SLAAC requirement be added (for IPv6).
On Sat, 2020-08-22 at 00:23 +0000, Gary Buhrmaster wrote:
On Sat, Aug 22, 2020 at 12:12 AM Adam Williamson adamwill@fedoraproject.org wrote:
It must be possible to establish both IPv4 and IPv6 network connections using DHCP and static addressing.
For IPV6, SLAAC is more common than DHCP(v6) (especially) in the consumer space. I would like to see a SLAAC requirement be added (for IPv6).
Oh, yeah, of course, that was silly of me. Thanks for pointing it out. Will amend in the next version.
On Fri, 2020-08-21 at 17:11 -0700, Adam Williamson wrote:
==== 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
VNC servers with typical configurations.
VNC == VPN?
Also, should we add WireGuard to this list for future-proofing?
Thanks,
On Tue, 2020-08-25 at 15:50 -0700, Michel Alexandre Salim wrote:
On Fri, 2020-08-21 at 17:11 -0700, Adam Williamson wrote:
==== 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
VNC servers with typical configurations.
VNC == VPN?
Oh, yes. Thanks.
Also, should we add WireGuard to this list for future-proofing?
It doesn't really make sense to add things to the release criteria for future proofing. If it's important *now* we should add it. Otherwise, no.
Do NetworkManager and its current KDE and GNOME front ends support it currently?
On Tue, 2020-08-25 at 16:11 -0700, Adam Williamson wrote:
On Tue, 2020-08-25 at 15:50 -0700, Michel Alexandre Salim wrote:
On Fri, 2020-08-21 at 17:11 -0700, Adam Williamson wrote:
==== 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
VNC servers with typical configurations.
VNC == VPN?
Oh, yes. Thanks.
Also, should we add WireGuard to this list for future-proofing?
It doesn't really make sense to add things to the release criteria for future proofing. If it's important *now* we should add it. Otherwise, no.
Do NetworkManager and its current KDE and GNOME front ends support it currently?
IIRC not - wireguard-tools is available, but setting up a connection is manual or needs to use the GUI/CLI from a VPN provider such as Mullvad
https://www.wireguard.com/quickstart/ https://mullvad.net/nl/help/install-mullvad-app-linux/ https://mullvad.net/en/help/how-use-mullvad-cli/
On Tue, Aug 25, 2020 at 4:11 pm, Adam Williamson adamwill@fedoraproject.org wrote:
Do NetworkManager and its current KDE and GNOME front ends support it currently?
Rumor has it that KDE has this working! But GNOME doesn't support it yet. Help welcome in these bugs:
https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/982 https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2989
Now, does wireguard work with systemd-resolved? *shrug* dunno!
On Tue, Aug 25, 2020 at 8:33 PM Michael Catanzaro mcatanzaro@gnome.org wrote:
On Tue, Aug 25, 2020 at 4:11 pm, Adam Williamson adamwill@fedoraproject.org wrote:
Do NetworkManager and its current KDE and GNOME front ends support it currently?
Rumor has it that KDE has this working!
The rumor is true! WireGuard has been supported in plasma-nm since Plasma 5.14.
It'd be nice to add validation for WireGuard to the criteria, but do we have a WireGuard VPN to test with?
But GNOME doesn't support it yet. Help welcome in these bugs:
https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/982 https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2989
Now, does wireguard work with systemd-resolved? *shrug* dunno!
It *should* work, since that part is managed by NetworkManager...
On Tue, 2020-08-25 at 21:20 -0400, Neal Gompa wrote:
On Tue, Aug 25, 2020 at 8:33 PM Michael Catanzaro < mcatanzaro@gnome.org> wrote:
On Tue, Aug 25, 2020 at 4:11 pm, Adam Williamson adamwill@fedoraproject.org wrote:
Do NetworkManager and its current KDE and GNOME front ends support it currently?
Rumor has it that KDE has this working!
The rumor is true! WireGuard has been supported in plasma-nm since Plasma 5.14.
It'd be nice to add validation for WireGuard to the criteria, but do we have a WireGuard VPN to test with?
Mullvad (they've added WireGuard support since before it was merged in kernel 5.6). For validation, do you mean as part of an automated test or as something individual contributors can test on their own? If the latter, I can sign up.
On Tue, Aug 25, 2020 at 10:51 PM Michel Alexandre Salim michel@michel-slm.name wrote:
Also, should we add WireGuard to this list for future-proofing?
I had thought about explicitly suggesting wireguard, but then thought that we should focus on what is currently being used, and while *I* use wireguard, it is still not really a common use case.
We do, of course, need to remember to regularly review all the criteria to make sure that they still make sense in the current environment and be willing to delete some things from the list when only a few still have such equipment or use the functionality.
I would almost suggest any addition should come with a criteria deletion, to bound the work for the QA team, who are, after all, a limited resource.
On Wed, 2020-08-26 at 01:14 +0000, Gary Buhrmaster wrote:
On Tue, Aug 25, 2020 at 10:51 PM Michel Alexandre Salim michel@michel-slm.name wrote:
Also, should we add WireGuard to this list for future-proofing?
I had thought about explicitly suggesting wireguard, but then thought that we should focus on what is currently being used, and while *I* use wireguard, it is still not really a common use case.
We do, of course, need to remember to regularly review all the criteria to make sure that they still make sense in the current environment and be willing to delete some things from the list when only a few still have such equipment or use the functionality.
I would almost suggest any addition should come with a criteria deletion, to bound the work for the QA team, who are, after all, a limited resource.
I **AM** THE QA TEAM
well, okay, not all of it. :P But yeah, I get the intention of that idea, but it wouldn't really work out. We do just need to add things sometimes. This is really about covering stuff that we would have wanted to block on anyway (and sometimes have, by stretching other criteria) but just hadn't ever written into the criteria.
We do drop things sometimes and make other adjustments like how we stopped requiring such extensive testing of physical media and restricted the desktop criteria a bit, a couple of releases back. But making it a strict one in/one out probably wouldn't be practical.
Also note that ensuring the products meets these criteria is meant to be a collaborative effort; the teams who build the products are supposed to share that responsibility with the QA team, including doing some of the actual testing.
I agree on the WireGuard front - that's what I meant by saying "It doesn't really make sense to add things to the release criteria for future proofing." The criteria should reflect *current* importance. Unless use of WireGuard is in the same ballpark as OpenVPN or Cisco etc. we probably wouldn't want to include it right now.
I *do* wonder if any of the other VPN plugins I see listed at https://wiki.gnome.org/Projects/NetworkManager/VPN but didn't include in the criterion are candidates. Does anyone have stats / practical knowledge of the relative popularity of all those?
On Fri, Aug 21, 2020 at 6:11 PM Adam Williamson adamwill@fedoraproject.org wrote:
==== Basic networking ====
It must be possible to establish both IPv4 and IPv6 network connections using DHCP and static addressing. The default network configuration tools for the console and for release-blocking desktops 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.
What about mDNS?
Something to the effect that if it's installed and enabled by a default package set for an edition, it should work (resolve and respond). That means it would apply to Workstation and KDE. It wouldn't apply to Cloud, or Server. I'm not sure if IoT enables it.
-- Chris Murphy
On Thu, 2020-08-27 at 10:06 -0600, Chris Murphy wrote:
On Fri, Aug 21, 2020 at 6:11 PM Adam Williamson adamwill@fedoraproject.org wrote:
==== Basic networking ====
It must be possible to establish both IPv4 and IPv6 network connections using DHCP and static addressing. The default network configuration tools for the console and for release-blocking desktops 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.
What about mDNS?
ehhhhhhh
I am probably a bit biased on this front because I always found mDNS to be a pile of garbage and gave up trying to use it a while back. :P But if a significant amount of people are actually using it and relying on it, adding it might make sense. Anyone else have input on this? Who out there does use mDNS?
On Fri, Aug 28, 2020 at 5:56 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2020-08-27 at 10:06 -0600, Chris Murphy wrote:
On Fri, Aug 21, 2020 at 6:11 PM Adam Williamson adamwill@fedoraproject.org wrote:
==== Basic networking ====
It must be possible to establish both IPv4 and IPv6 network connections using DHCP and static addressing. The default network configuration tools for the console and for release-blocking desktops 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.
What about mDNS?
ehhhhhhh
I am probably a bit biased on this front because I always found mDNS to be a pile of garbage and gave up trying to use it a while back. :P But if a significant amount of people are actually using it and relying on it, adding it might make sense. Anyone else have input on this? Who out there does use mDNS?
The IPP Everywhere specification requires clients to support DNS-SD (mDNS is part of that) or WS-Discovery. Printers are required to support both DNS-SD and WS-Discovery. Avahi and systemd-resolved support DNS-SD, functionally equating DNS-SD and mDNS.
Final release criterion says printing via the generic IPP driver must work. This implies discovery or you can't print. Or accept a craptastic user experience by fudging the requirement to say, well as long as an IP address works, the criterion is met.
It's even less of a leap if folks can't discover other services like SMB shares. That's more common than printing.
Between avahi and systemd-resolved, I'm not sure which one is more dependable for blocking on. Or whether their maintainers would be on board with such a criterion. At least for F33, Avahi is what we're using on desktops for this. Both resolve and respond are disabled in systemd-resolved so if it's better to do this with systemd-resolved, then it probably needs a Fedora 34 feature proposal.
On Sat, Aug 29, 2020 at 1:57 AM Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2020-08-27 at 10:06 -0600, Chris Murphy wrote:
On Fri, Aug 21, 2020 at 6:11 PM Adam Williamson adamwill@fedoraproject.org wrote:
==== Basic networking ====
It must be possible to establish both IPv4 and IPv6 network connections using DHCP and static addressing. The default network configuration tools for the console and for release-blocking desktops 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.
What about mDNS?
ehhhhhhh
I am probably a bit biased on this front because I always found mDNS to be a pile of garbage and gave up trying to use it a while back. :P But if a significant amount of people are actually using it and relying on it, adding it might make sense. Anyone else have input on this? Who out there does use mDNS?
I contact my machines (even VMs) through <hostname>.local every day, I'd be very angry if it didn't work, and I consider myself a significant amount of people ;o)
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.
[Sorry for the double post, somewhere along the way desktop@ and kde@ were dropped, so I'm re-adding them and that means double post for test@ and devel@.]
Re: add working mDNS to the criterion
The IPP Everywhere specification requires clients to support DNS-SD (mDNS is part of that) or WS-Discovery. Printers are required to support both DNS-SD and WS-Discovery. Avahi and systemd-resolved support DNS-SD, functionally equating DNS-SD and mDNS.
Final release criterion says printing via the generic IPP driver must work. This implies discovery or you can't print. Or accept a craptastic user experience by fudging the requirement to say, well as long as an IP address works, the criterion is met.
It's even less of a leap if folks can't discover other services like SMB shares. That's more common than printing.
Between avahi and systemd-resolved, I'm not sure which one is more dependable for blocking on. Or whether their maintainers would be on board with such a criterion. At least for F33, Avahi is what we're using on desktops for this. Both resolve and respond are disabled in systemd-resolved so if it's better to do this with systemd-resolved, then it probably needs a Fedora 34 feature proposal.
-- Chris Murphy
On Fri, Aug 28, 2020 at 7:52 PM Chris Murphy lists@colorremedies.com wrote:
The IPP Everywhere specification requires clients to support DNS-SD (mDNS is part of that) or WS-Discovery. Printers are required to support both DNS-SD and WS-Discovery. Avahi and systemd-resolved support DNS-SD, functionally equating DNS-SD and mDNS.
From the spec:
"Printers MUST publish a text (TXT) record that provides service information over mDNS. Printers that support dynamic DNS updates MUST publish separate TXT records for each domain that is updated."
I'm not completely certain, but I'm wondering whether it's possible to print IPP Everywhere at all, if DNS-SD or WS-Discovery aren't working on the client. Even having the IP address might not be enough.
I guess one way to test it would be to run the printing test case with an IPP Everywhere printer, and try to print with avahi stopped.
On Sat, Aug 29, 2020 at 4:34 AM Chris Murphy lists@colorremedies.com wrote:
On Fri, Aug 28, 2020 at 7:52 PM Chris Murphy lists@colorremedies.com wrote:
The IPP Everywhere specification requires clients to support DNS-SD (mDNS is part of that) or WS-Discovery. Printers are required to support both DNS-SD and WS-Discovery. Avahi and systemd-resolved support DNS-SD, functionally equating DNS-SD and mDNS.
From the spec:
"Printers MUST publish a text (TXT) record that provides service information over mDNS. Printers that support dynamic DNS updates MUST publish separate TXT records for each domain that is updated."
I'm not completely certain, but I'm wondering whether it's possible to print IPP Everywhere at all, if DNS-SD or WS-Discovery aren't working on the client. Even having the IP address might not be enough.
I guess one way to test it would be to run the printing test case with an IPP Everywhere printer, and try to print with avahi stopped.
Adding +Marek Kasik mkasik@redhat.com and +Zdenek Dohnal zdohnal@redhat.com who might know the answer.
Tom
On Fri, Aug 28, 2020 at 7:52 pm, Chris Murphy lists@colorremedies.com wrote:
Between avahi and systemd-resolved, I'm not sure which one is more dependable for blocking on. Or whether their maintainers would be on board with such a criterion. At least for F33, Avahi is what we're using on desktops for this. Both resolve and respond are disabled in systemd-resolved so if it's better to do this with systemd-resolved, then it probably needs a Fedora 34 feature proposal.
I don't know how to test mDNS, but it has been reported that it's broken in F33:
https://bugzilla.redhat.com/show_bug.cgi?id=1867830
That and the openconnect bug currently threaten the systemd-resolved change proposal.
Michael
On Sat, Aug 29, 2020 at 1:59 AM Adam Williamson adamwill@fedoraproject.org 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.
Sounds good to me.
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?
On Mon, Feb 28, 2022 at 12:37 PM Adam Williamson adamwill@fedoraproject.org wrote:
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?
I think it's sound enough to start using. I'm sure we'll find all sorts of edge cases to argue over and eventually fix. That's the Fedora Way™.
-
Adam Williamson -
Ben Cotton -
Chris Murphy -
Gary Buhrmaster -
Kamil Paral -
Michael Catanzaro -
Michel Alexandre Salim -
Neal Gompa -
Tomáš Popela