connman [was: Re: Proposal to Release Ubuntu 10.10 on 10.10.10]

Mark Shuttleworth mark at ubuntu.com
Tue May 11 11:02:02 BST 2010


On 11/05/10 10:40, Martin Pitt wrote:
> I concur that these two are rather unrelated, except of course the
> fact that _if_ we are going with connman, we would have a lot less
> time to stabilize it.

There is a fallback plan to NM if we are uncomfortable with ConnMan's
support for a broad enough cross section of the market.

> It seems we are discussing to replace NM (which we have banged on for
> 3 years, and is now working really well) with a new solution which we
> _know_ to be inferior. E. g. it excludes a major part of Russia
> (pppoe) and China (DSL). I do understand that connman has a nicer
> architecture and that NM is not very flexible, but I think we are
> giving up NM far too easily in favor of a solution which will cost us
> at least ten times the effort than it would cost us to change NM to
> use system-level connections by default (which it already supports,
> BTW).
>
> Also, we are discussing installing one in UNE and the other in
> GNOME/Kubuntu. Not only would this divert our development capacity and
> greatly reduce the amount of testing that we get during maverick, but
> it will also require us to do additional investments/hacks to not
> break GNOME: Right now, a connman-indicator would start up in GNOME
> regardless of whether nm-applet is already running, due to the totally
> different ways indicators and nm-applet start up.
>
> I think it's a great idea to start looking at connman now and taking
> it as a potential NM replacement (across the board) once it's on par
> with NM with the features of NM. I don't think it's a good idea to
> committing to using it in Maverick even before we have run a
> large-scale test with it.
>   

We have a full-time developer focused on the network stack. His opinion
is that ConnMan is a better basis for long term work, and we're going to
build a new UI based on it.

We know that ConnMan is weak w.r.t. widespread hardware and network
testing. But the only way to achieve that, is by giving it exposure. The
plan to adopt it in UNE is consistent with the aim of using it in a way
that affects a smaller user base. Based on that, we can address the
issues necessary to make it the default for the desktop as well.

Handling the relationship between ConnMan and NM when they are both
installed is standard integration work, which we are very good at :-)

Mark




More information about the technical-board mailing list