Re: [OpenDaylight TSC] A new project proposal: TrieMap

Sam Hague

On Thu, Sep 21, 2017 at 4:11 AM, Robert Varga <nite@...> wrote:
On 21/09/17 09:17, Anil Vishnoi wrote:
> At a high level this is the same issue that we came across with lldp
> library code and it end up moving to openflowplugin project. That
> probably was not ideal solution, but i believe comparing the trade-off
> of logistics cost of new project vs moving it to most relevant project
> made sense in that scenario.

We do have a precedent, where we split off a much smaller chunk of code
into a separate project -- tcpmd5 -- and there was essentially zero
overhead and no complications in doing that.

> Given that this code lived in yangtools till now and fairly stable code,
> also assuming that there is no downstream consumer of this code except
> yantools,

Controller does use it too, and I suspect there are other places which
could benefit from it.

> it seems reasonable to me to either keep it in yangtools or
> move it to infrautils (probably not ideal solution, but seems practical
> to me ). Given that there are only two pom.xml in this code base, not
> sure the effort spend in version bumping of this code really makes a
> strong reason for a new project (until and unless i missed something).

As I mentioned, infrautils simply does not cut it, it is nowhere near in
terms of stability.
If triemap was in infrautils, could the feature itself be stable independently of the other utils in the module?

I am not sure what version bumping effort you are referring to -- the
project will not participate in autorelease and given its API/ABI
stability, downstreams can easily use ranged dependency, completely
eliminating the need for version bumping procedures known from SR.

> I personally would like to move it to infrautils project, that way
> downstream projects also can leverage this implementation. If that is a
> possible option and the scope of the project is a problem then i think
> bringing that to discussion would be useful ( although looking at the
> scope of infrautils, i didn't find anything that's really blocker here).
does not cover it, and if that really is the current scope, infrautils
is already greatly exceeding its scope.
Sadly, the original scope was too limited. It should have had a wider scope to cover what we really wanted - which is a place to put useful utilities that other projects can consume without the need to create a new project. 

That actually brings about the question of what our governance is
regarding re-scoping projects -- I do not believe we have the equivalent
of IETF recharter process...
We rescoped NetVirt as part of pulling OVSDB out of it. Seemed like it was just a mini project proposal.


TSC mailing list

Join to automatically receive all group messages.