Re: 0.7 this year?

[Dan Williams <dcbw redhat com>]

On Sun, 2007-12-30 at 07:41 -0600, Rex Dieter wrote:
> Rex Dieter wrote:
> 
> > Bjoern Martensen wrote:
> > 
> >> how are the chances we might get our (desperately waiting) hands on NM
> >> 0.7 by the end of this year? maybe a christmas present? ;)
> > 
> > kde4/knetworkmanager lacks nm-0.7 support, with one of the excuses/reasons
> > being that nm-0.7 is not yet released.  So, the sooner it's released, the
> > better, hopefully within the f9 time-frame? :)
> 
> ping?
> 
> Not having a release or a visible schedule has some bad side-effects,
> primarily (from my pov) that downstream-apps and distros don't use it yet.
> 
> Of course, I'm asking out of selfishness, since a lack of release/schedule
> is the primary reason that kde4 (and knetworkmanager) doesn't yet support
> nm-0.7.

The more people we get contributing patches, the earlier it comes out :)
There are two major pieces left:

1) system settings (in-progress, patches gladly accepted): I worked on
the lockdown aspects this weekend; i.e. when a system connection is set
to override user connections for either a single device or for an SSID.
Lockdown is necessary for applets to intelligently display what
connections the user can actually use, as showing the user a connection
that just results in an error when they click it isn't useful at all.

Further tasks on this item:
   - (suse/fedora) Handle WPA options in ifcfg files
   - (suse/fedora) Handle PPP/serial ifcfg files
   - (suse/fedora) expand the ifcfg file syntax to handle VPNs
   - (debian/ubuntu) write the /etc/network/interfaces plugin
   - Make the applet show applicable system connections for devices
   - Make the applet show multiple connections for devices

2) multiple device support (patches gladly accepted): I'm going to start
this right after the system settings stuff gets further along unless
patches come by first.  We think most of the D-Bus API is OK for this
right now but that's impossible to completely state without getting more
work done here first.  The internal NetworkManager implementation
accounts for multiple devices already, but the activation/deactivation
behavior is what needs work here.

Further tasks on this item:
   - Write libnl code to manipulate routing table entries
   - "best" device gets the default route
   - Don't deactivate other devices when activating a device
   - Make the applet display multiple active devices
   - Make the applet allow device deactivation somehow

None of these are extremely hard.  Some are a matter of filling in the
blanks, others take a bit more engineering but not a ton.  I need to
spend some time working on stuff for the 0.6.x branch for the next 3
weeks or so as well.

Dan