[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 <[email protected]> > > wrote: > > > > On Tue, Sep 3, 2013 at 9:13 AM, Laszlo Papp <[email protected]> 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
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
