[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 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.

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/20130903/3164af8c/attachment-0002.sig>