On 21/07/17 00:32, Sam Hague wrote: > What was the reasoning not to absorb liblldp into the openflow project? > Because lldp isn't part of openflow? That makes sense and I don't think > we will find a project as this really is it's own protocol.
I do not agree with that -- LLDP is a full-blown protocol, but liblldp does not implement the data plane part of it (but hey, anyone could do that using liblldp). > For the sake of finding a good place to park it, though, ofp is a good > project since ofp uses the lib and genius and netvirt use ofp. I started off with thinking it would better be absorbed, but the mailing list discussion made me see the benefit of it being a separate project. > If not, what was the consensus on if we could reduce the process > requirements for making this it's own project? Could we just make the > project and let it automatically get pass on the milestones? Make it > such that we only have the startup costs to migrate it to a project, get > it building and leave it on auto-pilot. The primary reason is that this is self-contained piece of code, which depends on odlparent only and has utterly stable codebase. Note that odlparent is released independently of autorelease, which means so can this project. That means we only have to build this project once per odlparent release (if even necessary), test it once and then reuse it across downstream projects. No -SNAPSHOTS involved. Hence yes, this is a project-on-autopilot. It just needs a caretaker. That does not preclude it from being a fully active project in the future though. Regards, Robert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
