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.

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

https://wiki.opendaylight.org/view/Project_Proposals:Infrastructure_Utilities#Scope
does not cover it, and if that really is the current scope, infrautils
is already greatly exceeding its scope.

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

Regards,
Robert


_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc