Network Management to extragear/network

[Will Stephenson]

I'd like to propose that the Network Management stack
(libs,knetworkmanager,plasmoid) moves to extragear/network in time for KDE
4.4.  This way it's released but still has the schedule flexibility to react
to changes in NetworkManager and possibly other network management backend
systems.

Does anyone disagree with this?

Will
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

On Wednesday 04 November 2009 11:54:30 Will Stephenson wrote:
> I'd like to propose that the Network Management stack
> (libs,knetworkmanager,plasmoid) moves to extragear/network in time for KDE
> 4.4.  This way it's released but still has the schedule flexibility to
>  react  to changes in NetworkManager and possibly other network management
>  backend systems.

The Plasmoid is not ready yet, and might not be in time for 4.4. It's also not easy
to split off. I'd not build it for now so we don't have people accidentally using it
and then wonder why it doesn't work. I hope I can get some substantial improvements
in in time for 4.4, but there's a good chance that it won't be ready. Having the
plasmoid separate would certainly not help development of it, but I'm happy with a
separate review of this piece of code when the time comes. I hope people are OK with
this modus operandi?

That said, the other components are good to go into 4.4. They're being released by at
least two distros in their standard install and Will has been fixing bugs left and
right to make it solid.

> Does anyone disagree with this?

I think it's a good idea. Maybe kdebase is even a better (I consider connecting to
networks basic functionality), but as you note, upstream (networkmanager, connman,
wicd, ...) might require intermediate releases. We could probably still do those,
even if we end up in kdebase, of course.
--
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[Ian Monroe-6]

On Wed, Nov 4, 2009 at 5:38 AM, Sebastian Kügler <sebas@...> wrote:

> On Wednesday 04 November 2009 11:54:30 Will Stephenson wrote:
>> I'd like to propose that the Network Management stack
>> (libs,knetworkmanager,plasmoid) moves to extragear/network in time for KDE
>> 4.4.  This way it's released but still has the schedule flexibility to
>>  react  to changes in NetworkManager and possibly other network management
>>  backend systems.
>
> The Plasmoid is not ready yet, and might not be in time for 4.4. It's also not easy
> to split off. I'd not build it for now so we don't have people accidentally using it
> and then wonder why it doesn't work. I hope I can get some substantial improvements
> in in time for 4.4, but there's a good chance that it won't be ready. Having the
> plasmoid separate would certainly not help development of it, but I'm happy with a
> separate review of this piece of code when the time comes. I hope people are OK with
> this modus operandi?

I miss why moving to extragear means splitting anything up? Also not
wanting to release with 4.4 and have some more flexibility is a good
reason to be part of extragear. Its the whole point.

We shouldn't give any rule exceptions though, moving to extragear
means a 2 week stay in kdereview.

Ian
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

On Wednesday 04 November 2009 14:04:55 Ian Monroe wrote:

> On Wed, Nov 4, 2009 at 5:38 AM, Sebastian Kügler <sebas@...> wrote:
> > On Wednesday 04 November 2009 11:54:30 Will Stephenson wrote:
> >> I'd like to propose that the Network Management stack
> >> (libs,knetworkmanager,plasmoid) moves to extragear/network in time for
> >> KDE 4.4.  This way it's released but still has the schedule flexibility
> >> to react  to changes in NetworkManager and possibly other network
> >> management backend systems.
> >
> > The Plasmoid is not ready yet, and might not be in time for 4.4. It's
> > also not easy to split off. I'd not build it for now so we don't have
> > people accidentally using it and then wonder why it doesn't work. I hope
> > I can get some substantial improvements in in time for 4.4, but there's a
> > good chance that it won't be ready. Having the plasmoid separate would
> > certainly not help development of it, but I'm happy with a separate
> > review of this piece of code when the time comes. I hope people are OK
> > with this modus operandi?
>
> I miss why moving to extragear means splitting anything up? Also not
> wanting to release with 4.4 and have some more flexibility is a good
> reason to be part of extragear. Its the whole point.
>
> We shouldn't give any rule exceptions though, moving to extragear
> means a 2 week stay in kdereview.

I wasn't clear enough, sorry. :)

The whole networkmanager thing has two clients right now. A 'systray' (sorry,
statusnotifier!) based one, called knetworkmanager. This is a separate executable,
and pretty stable. It's also the one shipped with openSuse and Kubuntu (at least).
Then, there's the Plasmoid, which is more shiny, but also not quite finished.

Both clients are currently part of the networkmanager/ directory, which we'd like to
move into a released module for 4.4. They're making use of the same underlying
library to interact with networkmanager (and possibly other middleware stuff doing
the same, think of connman). So: underlying mechanisms are shared, there are two UIs.

As the plasmoid is not ready for consumption, it probably shouldn't end up on users'
systems, but I also wouldn't like to keep it separate since it's closely entangled
with the rest of networkmanager. The knetworkmanager thing on the other hand is IMO
close enough to release quality.

My proposal in more detail:

- move networkmanager/ to a released module (through usual kdereview process)
- exclude networkmanager/plasma for now, but keep it in the same location
- as soon as we feel confident enough about the plasmoid, we'll have it reviewed
  separately before it ends up in a release

For the NM plasmoid, I'm aiming at 4.5. Realistically, without additional manpower
the plasmoid won't be ready for 4.4.
--
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[Will Stephenson]

On Wednesday 04 November 2009 14:26:50 Sebastian Kügler wrote:

> On Wednesday 04 November 2009 14:04:55 Ian Monroe wrote:
> > On Wed, Nov 4, 2009 at 5:38 AM, Sebastian Kügler <sebas@...> wrote:
> > > On Wednesday 04 November 2009 11:54:30 Will Stephenson wrote:
> > >> I'd like to propose that the Network Management stack
> > >> (libs,knetworkmanager,plasmoid) moves to extragear/network in time for
> > >> KDE 4.4.  This way it's released but still has the schedule
> > >> flexibility to react  to changes in NetworkManager and possibly other
> > >> network management backend systems.
> > >
> > > The Plasmoid is not ready yet, and might not be in time for 4.4. It's
> > > also not easy to split off. I'd not build it for now so we don't have
> > > people accidentally using it and then wonder why it doesn't work. I
> > > hope I can get some substantial improvements in in time for 4.4, but
> > > there's a good chance that it won't be ready. Having the plasmoid
> > > separate would certainly not help development of it, but I'm happy with
> > > a separate review of this piece of code when the time comes. I hope
> > > people are OK with this modus operandi?
> >
> > I miss why moving to extragear means splitting anything up? Also not
> > wanting to release with 4.4 and have some more flexibility is a good
> > reason to be part of extragear. Its the whole point.
> >
> > We shouldn't give any rule exceptions though, moving to extragear
> > means a 2 week stay in kdereview.

Right, I wasn't asking for an exception - just giving notice of intent to move
in case I overlooked anything.

> I wasn't clear enough, sorry. :)
>
> The whole networkmanager thing has two clients right now. A 'systray'
>  (sorry, statusnotifier!) based one, called knetworkmanager. This is a
>  separate executable, and pretty stable. It's also the one shipped with
>  openSuse and Kubuntu (at least). Then, there's the Plasmoid, which is more
>  shiny, but also not quite finished.
>
> Both clients are currently part of the networkmanager/ directory, which
>  we'd like to move into a released module for 4.4. They're making use of
>  the same underlying library to interact with networkmanager (and possibly
>  other middleware stuff doing the same, think of connman). So: underlying
>  mechanisms are shared, there are two UIs.
>
> As the plasmoid is not ready for consumption, it probably shouldn't end up
>  on users' systems, but I also wouldn't like to keep it separate since it's
>  closely entangled with the rest of networkmanager. The knetworkmanager
>  thing on the other hand is IMO close enough to release quality.
>
> My proposal in more detail:
>
> - move networkmanager/ to a released module (through usual kdereview
>  process) - exclude networkmanager/plasma for now, but keep it in the same
>  location - as soon as we feel confident enough about the plasmoid, we'll
>  have it reviewed separately before it ends up in a release
>
> For the NM plasmoid, I'm aiming at 4.5. Realistically, without additional
>  manpower the plasmoid won't be ready for 4.4.

Agreed - although mattr is making manpower noises about it on kde-
networkmanager...

Will
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[Aaron J. Seigo]

On November 4, 2009, Sebastian Kügler wrote:

> On Wednesday 04 November 2009 11:54:30 Will Stephenson wrote:
> > I'd like to propose that the Network Management stack
> > (libs,knetworkmanager,plasmoid) moves to extragear/network in time for
> > KDE 4.4.  This way it's released but still has the schedule flexibility
> > to react  to changes in NetworkManager and possibly other network
> > management backend systems.
>
> The Plasmoid is not ready yet, and might not be in time for 4.4. It's also
>  not easy to split off. I'd not build it for now so we don't have people
>  accidentally using it and then wonder why it doesn't work. I hope I can
>  get some substantial improvements in in time for 4.4, but there's a good
>  chance that it won't be ready.

can we get a short meeting on irc together to discuss what needs to be done
for 4.4? it's bordering on the ridiculous that we don't have this done 2 years
into kde 4 releases, so let's make it a priority, figure out what's needed and
then get the manpower on it.

> > Does anyone disagree with this?
>
> I think it's a good idea. Maybe kdebase is even a better (I consider
>  connecting to networks basic functionality), but as you note, upstream
>  (networkmanager, connman, wicd, ...) might require intermediate releases.
>  We could probably still do those, even if we end up in kdebase, of course.

yes, i don't see how being in kdebase means no interim releases.

--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

On Wednesday 04 November 2009 07:42:26 Will Stephenson wrote:

> On Wednesday 04 November 2009 14:26:50 Sebastian Kügler wrote:
> > On Wednesday 04 November 2009 14:04:55 Ian Monroe wrote:
> > > On Wed, Nov 4, 2009 at 5:38 AM, Sebastian Kügler <sebas@...> wrote:
> > > > On Wednesday 04 November 2009 11:54:30 Will Stephenson wrote:
> > > >> I'd like to propose that the Network Management stack
> > > >> (libs,knetworkmanager,plasmoid) moves to extragear/network in time
> > > >> for KDE 4.4.  This way it's released but still has the schedule
> > > >> flexibility to react  to changes in NetworkManager and possibly
> > > >> other network management backend systems.
> > > >
> > > > The Plasmoid is not ready yet, and might not be in time for 4.4. It's
> > > > also not easy to split off. I'd not build it for now so we don't have
> > > > people accidentally using it and then wonder why it doesn't work. I
> > > > hope I can get some substantial improvements in in time for 4.4, but
> > > > there's a good chance that it won't be ready. Having the plasmoid
> > > > separate would certainly not help development of it, but I'm happy
> > > > with a separate review of this piece of code when the time comes. I
> > > > hope people are OK with this modus operandi?
> > >
> > > I miss why moving to extragear means splitting anything up? Also not
> > > wanting to release with 4.4 and have some more flexibility is a good
> > > reason to be part of extragear. Its the whole point.
> > >
> > > We shouldn't give any rule exceptions though, moving to extragear
> > > means a 2 week stay in kdereview.
>
> Right, I wasn't asking for an exception - just giving notice of intent to
>  move in case I overlooked anything.
>
> > I wasn't clear enough, sorry. :)
> >
> > The whole networkmanager thing has two clients right now. A 'systray'
> >  (sorry, statusnotifier!) based one, called knetworkmanager. This is a
> >  separate executable, and pretty stable. It's also the one shipped with
> >  openSuse and Kubuntu (at least). Then, there's the Plasmoid, which is
> > more shiny, but also not quite finished.
> >
> > Both clients are currently part of the networkmanager/ directory, which
> >  we'd like to move into a released module for 4.4. They're making use of
> >  the same underlying library to interact with networkmanager (and
> > possibly other middleware stuff doing the same, think of connman). So:
> > underlying mechanisms are shared, there are two UIs.
> >
> > As the plasmoid is not ready for consumption, it probably shouldn't end
> > up on users' systems, but I also wouldn't like to keep it separate since
> > it's closely entangled with the rest of networkmanager. The
> > knetworkmanager thing on the other hand is IMO close enough to release
> > quality.
> >
> > My proposal in more detail:
> >
> > - move networkmanager/ to a released module (through usual kdereview
> >  process) - exclude networkmanager/plasma for now, but keep it in the
> > same location - as soon as we feel confident enough about the plasmoid,
> > we'll have it reviewed separately before it ends up in a release
> >
> > For the NM plasmoid, I'm aiming at 4.5. Realistically, without additional
> >  manpower the plasmoid won't be ready for 4.4.
>
> Agreed - although mattr is making manpower noises about it on kde-
> networkmanager...
>

Indeed, if someone can provide a semi-concrete TODO, I would be willing to
devote some time to this.
--
Matt


 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[Will Stephenson]

On Wednesday 04 November 2009 22:51:16 Aaron J. Seigo wrote:
> > I think it's a good idea. Maybe kdebase is even a better (I consider
> >  connecting to networks basic functionality), but as you note, upstream
> >  (networkmanager, connman, wicd, ...) might require intermediate
> > releases. We could probably still do those, even if we end up in kdebase,
> > of course.
>
> yes, i don't see how being in kdebase means no interim releases.
>
I'm against kdebase for several reasons.  I reject the trend to move
everything that might be construed as basic functionality to kdebase - KDE
works just fine without a NetworkManager,wicd,connman client on a desktop with
static networking, and on several other platforms which have their own
networkmanagement stacks.

No-one will ignore or not find KNM if it's in extragear.

And my experience was that Kopete moving to main modules at that point in its
lifecycle killed innovation.  If we did interim releases as well as kdebase
releases we'd always be competing with the main module releases, as well as
trying to figure out whether 'I use knetworkmanager on 4.3.3' in a BR meant
the copy shipped with 4.3.3 or a later interim release.

Will
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

On Wednesday 04 November 2009 22:51:16 Aaron J. Seigo wrote:

>   On November 4, 2009, Sebastian Kügler wrote:
> > On Wednesday 04 November 2009 11:54:30 Will Stephenson wrote:
> > > I'd like to propose that the Network Management stack
> > > (libs,knetworkmanager,plasmoid) moves to extragear/network in time for
> > > KDE 4.4.  This way it's released but still has the schedule flexibility
> > > to react  to changes in NetworkManager and possibly other network
> > > management backend systems.
> >
> >
> > The Plasmoid is not ready yet, and might not be in time for 4.4. It's
> > also not easy to split off. I'd not build it for now so we don't have
> > people accidentally using it and then wonder why it doesn't work. I hope
> > I can get some substantial improvements in in time for 4.4, but there's a
> > good chance that it won't be ready.
>
> can we get a short meeting on irc together to discuss what needs to be
>  done  for 4.4? it's bordering on the ridiculous that we don't have this
>  done 2 years into kde 4 releases, so let's make it a priority, figure out
>  what's needed and then get the manpower on it.

I'd be in to make this a priority for 4.4 and will put work into it, prioritizing it
over other things.

How about we meet Friday night, maybe 1800 UTC? I can reserve the rest of the night
for hacking, so we get some immediate progress.
--
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

On Thursday 05 November 2009 04:07:26 Matt Rogers wrote:
> > > For the NM plasmoid, I'm aiming at 4.5. Realistically, without
> > > additional manpower the plasmoid won't be ready for 4.4.
> >
> > Agreed - although mattr is making manpower noises about it on kde-
> > networkmanager...
>
> Indeed, if someone can provide a semi-concrete TODO, I would be willing to
> devote some time to this.

I had a look the other night. I encountered the immediate problems:

- knm doesn't show up in my trunk systray. The app seems to start and run, but the
  statusnotifier won't show up in the systray. That's up to date trunk.
- The Plasmoid doesn't compile right now due to some moving of classes, probably not
  that hard to fix
- Clicking on items didn't have any effect. This is likely a problem not specific to
  the plasmoid, possibly D-Bus permissions. As far as I could trace it, the
  networkmanager part is fine, the signal doesn't make it across the bus to
  NetworkManager it seems

From there on, it's testing stuff and fixing the resulting breakage. Most pieces are
in place, and once the D-Bus problem is sorted, it should work for at least wired and
wireless networks. I couldn't test VPN and G3 stuff, since I don't have such
connections available, hardware-/service-wise.

Code is in http://websvn.kde.org/trunk/playground/base/plasma/applets/networkmanager/
--
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

On Thursday 05 November 2009 05:14:13 am Sebastian Kügler wrote:

> On Wednesday 04 November 2009 22:51:16 Aaron J. Seigo wrote:
> >   On November 4, 2009, Sebastian Kügler wrote:
> > > On Wednesday 04 November 2009 11:54:30 Will Stephenson wrote:
> > > > I'd like to propose that the Network Management stack
> > > > (libs,knetworkmanager,plasmoid) moves to extragear/network in time
> > > > for KDE 4.4.  This way it's released but still has the schedule
> > > > flexibility to react  to changes in NetworkManager and possibly other
> > > > network management backend systems.
> > >
> > > The Plasmoid is not ready yet, and might not be in time for 4.4. It's
> > > also not easy to split off. I'd not build it for now so we don't have
> > > people accidentally using it and then wonder why it doesn't work. I
> > > hope I can get some substantial improvements in in time for 4.4, but
> > > there's a good chance that it won't be ready.
> >
> > can we get a short meeting on irc together to discuss what needs to be
> >  done  for 4.4? it's bordering on the ridiculous that we don't have this
> >  done 2 years into kde 4 releases, so let's make it a priority, figure
> > out what's needed and then get the manpower on it.
>
> I'd be in to make this a priority for 4.4 and will put work into it,
>  prioritizing it over other things.
>
> How about we meet Friday night, maybe 1800 UTC? I can reserve the rest of
>  the night for hacking, so we get some immediate progress.
>

I don't have any availability before 0200 UTC so if the meeting already
happened, I didn't make it. Are there logs somewhere I can read?
--
Matt
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

On Wednesday 11 November 2009 05:48:26 Matt Rogers wrote:
> > How about we meet Friday night, maybe 1800 UTC? I can reserve the rest of
> >  the night for hacking, so we get some immediate progress.
>
> I don't have any availability before 0200 UTC so if the meeting already
> happened, I didn't make it. Are there logs somewhere I can read?

I don't think we logged it, though we did progress quite well over the last weekend.
I'll be hacking on NM tomorrow night again, we could surely meet up on IRC, maybe
around 1900, UTC, #plasma?
--
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<