New upstream version 1.16.0 upstream/1.16.0

1 files changed, 7 insertions, 7 deletions

diff --git a/TODO b/TODO
index e13953de..a8785bbc 100644
--- a/TODO
+++ b/TODO
@@ -18,7 +18,7 @@ of each device's state.  Unfortunately that requires two things:
 The first is the largest obstacle, but ideally we implement this and enable it
 when we have the required glib and libsoup versions available.  One other
 complication is that this checking should be done during the
-NM_DEVICE_STATE_IP_CHECK phase (along with other operations like WiFi hotspot
+NM_DEVICE_STATE_IP_CHECK phase (along with other operations like Wi-Fi hotspot
 auto-login) while the current checks are done globally in nm-manager.c, so
 keeping both code paths might be complex.
 
@@ -97,7 +97,7 @@ same MAC address, the connection with the most recent timestamp should be
 preferred.
 
 Similarly, if the probing/listening process detects 802.1x frames the device
-should be marked as requring 802.1x authentication until the carrier drops.
+should be marked as requiring 802.1x authentication until the carrier drops.
 This would be accomplished by adding a new property to the NMDeviceEthernet
 object and exporting that property through the
 introspection/nm-device-ethernet.xml file.  This would allow clients like
@@ -109,10 +109,10 @@ successfully connect to this network.
 * VPN re-connect (bgo #349151)
 
 NM should remember whether a VPN was connected if a connection disconnects
-(like WiFi drops out or short carrier drop) or if the laptop goes to sleep.
+(like Wi-Fi drops out or short carrier drop) or if the laptop goes to sleep.
 Upon reconnect, if the same Connection is again active, the previously
 connected VPN should be activated again as well.  Basically, don't just drop
-the VPN because WiFi choked for 10 seconds, but reconnect the VPN if it was
+the VPN because Wi-Fi choked for 10 seconds, but reconnect the VPN if it was
 connected before the drop.
 
 
@@ -231,7 +231,7 @@ proceeds with the connection.
 
 NM sends the correct wpa_supplicant config for WPS to the supplicant, and waits
 for the connection to occur.  WPS can only be used the *first* time, so after a
-first successfull connection, NM must request the actual hexadecimal PSK from
+first successful connection, NM must request the actual hexadecimal PSK from
 wpa_supplicant via D-Bus, and store that PSK in the connection, clear any WPS
 PIN code from the connection, and save the connection to backing storage.
 
@@ -248,7 +248,7 @@ There are a few components to this:
 1) kernel driver and hardware capabilities: most mobile devices use periodic
 background scanning to quickly determine whether a known SSID is available and
 notify the connection manager to connect to it.  This typically requires special
-capabilities and good powersave/sleep support from the WiFi kernel driver.
+capabilities and good powersave/sleep support from the Wi-Fi kernel driver.
 There is a background scanning API in nl80211, but we need to determine how many
 SSIDs each driver allows for background scanning, and based on that number, give
 the driver the most recent N SSIDs.  We still need to periodically wake the
@@ -283,7 +283,7 @@ connection process.
 2) single-device-at-a-time with overlapping connections: this is also probably
 the best route to go for desktop use-cases as well.  Instead of bringing all
 available connections up, only bring up the "best" connection at any given
-time based on the current priority list (which is rougly Ethernet > WiFi >
+time based on the current priority list (which is roughly Ethernet > Wi-Fi >
 3G/Bluetooth).  However, to ensure seamless connectivity, when one connection
 begins to degrade, the next-best connection should be started before the
 current one is terminated, such that there is a small amount of overlap.