On 21/09/17 15:21, Sam Hague wrote:
>
>
> On Thu, Sep 21, 2017 at 4:11 AM, Robert Varga <nite@...

> <mailto: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?

The karaf feature could be marked as stable, but it would still have to
branch and version bump with the rest of the project -- exactly the as
it has to in yangtools.

Avoiding that churn is at this moment key driver behind the proposal.

>     https://wiki.opendaylight.org/view/Project_Proposals:Infrastructure_Utilities#Scope
>     <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.
>
> 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.

I am not convinced that actually was necessary.

Examining current autorelease, the only beneficiary was daexim using the
ready service. All other users already depend on genius, where most of
the utilities existed -- hence there those utilities could have stayed
in genius.

https://stackoverflow.com/questions/3305511/is-it-good-to-have-utils-class-in-your-software-project,
answers 2 (and 3) give a good summary why Utils classes are not a good
thing in the long term. Having that at project level is very much the
same thing.

This has been raised during discussions leading to infrautils proposal
and creation review, at this point everything that looks like a
semi-reusable piece of code is now considered to be in scope of infrautils.

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

... which actually was reviewed and approved by the TSC. I do not
believe such a thing happened with infrautils, or have I missed something?

Regards,
Robert