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


Robert Varga
 

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

Join project-proposals@lists.opendaylight.org to automatically receive all group messages.