Working together on NM09 support and cleaning Solid::Control

[Will Stephenson]

On Thursday 19 May 2011 13:25:09 Kevin Kofler wrote:
> Will Stephenson wrote:
> > Use of NM09 in distros is more interesting and the only distro to have
> > shipped in (Fedora) has already done so and has it own solution. The next
> > round of distro releases comes in the autumn by which time our NM09
> > support will be complete.
> 
> Unfortunately, this is not an accurate characterization of the situation in
> Fedora.
> 
> First of all, the Rawhide (our rolling development tree, from which Fedora
> 16 will eventually be branched) NetworkManager packages do not and will
> not include the compatibility API. So we need something to put into
> Rawhide NOW. Right now kde-plasma-networkmanagement is completely broken
> in Rawhide. We're going to import a snapshot of the nm09 branch into
> Rawhide ASAP. This need not be perfect (hey, it's Rawhide! ;-) ), but at
> least it should work to some extent, and ideally get fixes actively. I'd
> also expect other distributions targeting a fall release to want to start
> importing NM 0.9 and the nm09 branch of kde-plasma-networkmanagement now
> rather than in fall; see e.g. the reply from the Debian maintainer about
> the plans for Debian and Ubuntu.
>
> Secondly, in Fedora 15, the situation is as follows:
> 1. The Fedora NetworkManager package maintainers only guaranteed us that
> they will be maintaining the compatibility API until summer (i.e.
> June-August, they weren't more specific). They expect us to have pushed a
> kde-plasma- networkmanagement update which uses the native 0.9 API by
> then. (The KDE SC 4.7.0 release was mentioned as a possible date for the
> switch.)
> 2. There are other strong reasons why we want to move Fedora 15 to the
> native 0.9 API ASAP (even before 4.7.0 if possible!):
> (i) VPN support is broken in the NM compatibility interface:
> https://bugzilla.redhat.com/show_bug.cgi?id=699786 and our NetworkManager
> maintainers show no interest in fixing it.
> (ii) The compatibility API only supports the exact feature set (modulo
> broken VPN, see above) of the 20110323 snapshot of
> kde-plasma-networkmanagement. In particular, it does NOT support:
> * system connections,
> * bluetooth tethering,
> * anything else added to kde-plasma-networkmanagement after around March
> 23. So, since we don't want to expose non-working UI to our users, we are
> stuck with the 20110323 snapshot on Fedora 15, and for upgrade path
> reasons also on Fedora 14. But our users are asking for newer snapshots.

This is the same situation we have in openSUSE Factory today, so take it from 
me I am under the same kind of pressure to get something working.


> 3. Another important thing to consider is that we need to have support for
> properly migrating existing user connections (to connections stored as
> system connections, but set to be private for the user, and with the
> secrets stored per user through the secrets agent interface) before we can
> push the nm09 branch builds as an update to Fedora 15. The proposed
> workaround of manually switching the connections to system connections
> before upgrading is not suitable for several reasons:
> (i) It does not work on Fedora 15 at all, because the compatibility API
> does not support system connections!
> (ii) Even if it did, pushing an update which requires you to manually tweak
> your configuration before updating would not be acceptable.
> (iii) It means storing the secrets in systemwide (and thus unencrypted)
> storage, which might not be what you want.

Also affects us.

> So the recent work on getting the nm09 branch up to task quickly is great
> news to us; having that work be halted in favor of a major refactoring
> which is scheduled to take until fall would be a HUGE problem for Fedora!

Until now we agree, but you misunderstand the scope of the work.  Sorry for 
misleading you by my (incorrect) assumption that you were off the hook until 
later in the year:

The refactoring is no more than that currently underway in nm09 branch:  
Reasons:
* It consists of a removal of the Solid::Control abstraction layers over the 
networkmanager-0.7 backend and a renaming to libnm-qt
* Since the Solid::Control API design was largely a copy of the NM 0.7 API, 
the underlying backend has the same semantics as Solid::Control
* Therefore the refactoring = library rename + class renames + NM 0.9 API 
changes.  Compare this to what is currently in the nm09 branch: library rename 
(solidcontrolnm09) + class renames (+="Nm09") + NM 0.9 API changes. 
* We keep the feature work since march 23.

The advantage is that we end up with one clean source tree for NM09 going 
forward and no Solid::Control to maintain in KDE 4.7.

The extra work to do this vs proceeding with the code now in nm09 branch is 
that needed to merge the nm09 work since Saturday in nm09 branch back into my 
libnm-qt branch of networkmanagmeent - it's worth paying that cost now rather 
than the larger costs to refactor/cleanup later.

Will