Re: Approaching NetworkManager 1.2

[poma <pomidorabelisima gmail com>]

On 02.11.2015 18:02, Lubomir Rintel wrote:
> Hello everyone,
>
> It's been some time since the work on NetworkManager 1.2 has begun. A
> lot of what's been planed has been implemented and we believe we should
> wrap up the work and do a major release.
>
> The wiki page with 1.2 feature page has been updated with the features
> we're like to see in the release (most of it already implemented):
> https://wiki.gnome.org/Projects/NetworkManager/12FeaturesPlanning
>
> If anyone believes anything important is missing it's a good time to
> speak up now.

Thanks for the offer,

- applet: drop bond, bridge, infiniband, team, and vlan support
  https://git.gnome.org/browse/network-manager-applet/commit/?id=4b8eade

<quote>
At one point we thought people would want/need to control their "enterprisey" devices via nm-applet, but 
nmcli (or static autoconnect=true configuration) turns out to be a better answer generally.

Additionally, probably the most common case of bridges currently is when you are using virtualization or 
containers, and in that case the bridge is handled entirely by the virt/container system, and showing it in 
nm-applet just clutters things up, pushing Wi-Fi and VPN down to the bottom of the menu.

So drop support for those devices.

https://bugzilla.gnome.org/show_bug.cgi?id=753369
</quote>


Bridges are "enterprisey" devices, really?


- drop support for enterprisey device types
  https://bugzilla.gnome.org/show_bug.cgi?id=753369#c0

<quote>
nm-applet tends to get cluttered up with virbr devices these days, and I think gnome-shell's approach (only 
showing ethernet, wifi, bluetooth, and mobile) is probably the right thing for GUIs. I really doubt anyone is 
using nm-applet to manage their team devices...
</quote>

Something is "cluttered" to -you- or to the -GNOME- "design"? :)
Let's leave the GNOME to use what it uses, but do not take from the network-manager-applet.

Please bring the bridges back to network-manager-applet!


> Since the new release will bring significant changes, we'll be doing a
> beta release (likely towards the end of this year) once the new APIs
> are settled.
>
> When the remaining work that won't involve interface changes is done
> we'll do a release candidate and repeat that until the wrinkles are
> ironed out and the feedback is sufficiently good.
>
> Thanks,
> Lubo