[oe] [meta-networking][PATCH] openflow: Add latest from git

[Joe MacDonald]

[Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.03 (Tue 17:18) Joe MacDonald wrote:

> [Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.03 (Tue 14:47) Laszlo Papp wrote:
> 
> > On Tue, Sep 3, 2013 at 2:38 PM, Bruce Ashfield <bruce.ashfield at gmail.com>
> > wrote:
> > 
> >     On Tue, Sep 3, 2013 at 9:13 AM, Laszlo Papp <lpapp at kde.org> wrote:
> >     > IMO, most of this email is red herring, and the main topic is a
> >     networking
> >     > specification should be in meta-networking. Why would I (or anyone for
> >     that
> >     > matter) need *any* virtualization layer when I am working on a network
> >     > device?
> > 
> >     Ah, so I see we won't address the fact that the mailing list should have
> >     been consulted and that the goals of the oe-layers should be to reduce
> >     duplication and get everyone working together. I promise, I won't mention
> >     this again, but it is a key point I want to make.
> > 
> > 
> > Frankly, you have mentioned the credit so strongly in this thread for a few
> > lines which is not even copyright'd, I will rewrite this stuff from scratch
> > today.
> 
> It may be that that's an appropriate approach at this juncture, I don't
> know.  I'd like to see us not lose any work that's already been done and
> would be disappointed if something turns out to be a regression in the
> meta-networking version of openflow from the meta-virtualization version
> purely due to a communications breakdown.  I'll trust you guys to sort
> that out.
> 
> My only comment on what I've seen so far is maybe in the commit log
> remove the 2) comment as it borders on editorializing and update the log
> to match more of the style of recipes ported from "the world" (mostly OE
> Classic, so far, for meta-networking).  See 2cde4a, 8fec90, or 413a9 for
> something I think is a good way to reference history.

Hey Laszlo,

Just to close on this, if Bruce (or someone working with
meta-virtualization) is nearing completion of testing with the recipe
you've already submitted, is that the one you want me to consider for
merging, or are you going to have a v2 coming out soon?

FYI:  I expect to be done merging your other patch (the stunnel one)
later on today.  It didn't get lost, I just didn't get to merge it
yesterday.

-J.

> 
> Thanks,
> -J.
> 
> > I am sad to see this discussion is going into "credit debate" rather
> > than technical stuff.
> > 
> > Actually, I even had a recipe before looking into virtualization, but that
> > probably does not matter for you...
> > 
> > 
> >     > I am sorry for your historical misplacement, but it is not an excuse for
> >     > future mistakes IMHO. If your virtualization depends on network stuff,
> >     you
> >     > should *not* force others for virtualization whatever that is. If you
> >     need
> >     > that, build on top of networking or use own recipes maintained by you.
> > 
> >     I don't agree with that characterization, since it is very black and white.
> > 
> >     Having a binding to the larger meta-oe universe (at least for some
> >     recipes),
> >     isn't always a good thing, and having self contained layers is also
> >     something
> >     that is a goal at times. I'm not saying this is the case here, just that
> >     what
> >     you describe above about networking devices not wanting virtualization,
> >     is at times flipped around from other layers when looking at meta-oe.
> > 
> >     meta-virt and meta-networking are very similar in age and the group of
> >     recipes to start meta-virt were a merging of two existing layers (a good
> >     collaboration) and a lot contributed by ENEA, it was a good effort and I
> >     don't think it's right to drop all traces of that effort or describe it as
> >     a
> >     mistake.
> > 
> >     Again, opinions vary, that's part of the fun.
> > 
> > 
> > The problem is not that opinions matter, but *your* opinion about black being
> > white IMHO. Did you even bother to read what the openflow standard is for? It
> > is for networking devices, come on, and you still think it is not a
> > meta-networking material?
> > 
> > Please come up with a *rebruttal* and bother substantiating it.
> >  
> > 
> >     > I fail to see how it is a problem. Even more, the recipe was completely
> >     > broken like virtual/libc, *ancient* version, wrong rm'f stuff, bad
> >     > description IMHO, etc for meta-networking.
> > 
> >     Patches would have been accepted :)
> > 
> > 
> > Here is the patch, so what is your argument again? That it should remain in
> > your beloved meta-virtualization while disregarding the fact it is a networking
> > standard?
> > 
> > I do not seem to have pushed the latest version of the change though. 
> > 
> > 
> >     > I do not personally mind if you keep your clone because it is your
> >     > business, but surely, networking devices should use a network layer, and
> >     > that is exactly the point of meta-networking.
> > 
> >     I'll agree to disagree, I've tried to say that we should look at what the
> >     two
> >     layers need, come up with a plan, keep the credit to the original authors
> >     and then decide how to move forward. i.e. if there are multiple users of
> >     the
> >     recipe, maybe see about getting it into oe-core, etc. But I see that isn't
> >     on
> >     the menu today.
> > 
> > 
> > oe-core would not make sense for this. It is *far* from being that core
> > component. It is actually a very domain specific networking  component.
> >  
> > 
> >     I'll ping Joe and we'll see what we can figure out as timing for a path
> >     forward.
> > 
> > 
> > There is no *any* need to ping him. This change was sent to the mailing list as
> > instructed by the meta-networking layer manual, hence he will see it. Please
> > keep this "ping" in public, and do not hide this behind the scenes in private.
> > The more eyes, the better.
> 
-- 
-Joe MacDonald.
:wq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20130904/80040f4c/attachment-0002.sig>