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

Anil Vishnoi

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.

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

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

On Wed, Sep 20, 2017 at 6:39 AM, Michael Vorburger <vorburger@...> wrote:
On Wed, Sep 20, 2017 at 2:47 PM, Robert Varga <nite@...> wrote:
On 20/09/17 14:10, Michael Vorburger wrote:
> On Mon, Sep 18, 2017 at 3:49 PM, Robert Varga <nite@...
> <mailto:nite@...>> wrote:
>     Hello everyone,
>     I would like to propose a new project, TrieMap, as detailed in
>     <>.
>     This would be an Oxygen-timeframe spin-off from YANG Tools, which is
>     currently hosting the codebase due to it being the topmost project
>     requiring the implementation.
>     There are three reasons for splitting the code from YANG Tools:
>     - the code is outside of scope of YANG Tools
>     - the code does not have any dependencies on other code in YANG Tools
>     - the code is almost feature-complete at this stage and very stable,
>     hence would benefit from independent versioning
>     Please review the proposal, any feedback is welcome.
> an entire formal new ODL project for these... 5 classes strikes me as ..
> curious.

nite@nitebug : ~/odl/yangtools/third-party/triemap on  $ find . -name
\*.java | wc -l

nite@nitebug : ~/odl/yangtools/third-party/triemap on  $ find . -name
\*.java | xargs wc -l | tail -n 1
  4691 total

e.g. 51 classes for 4.7KLOC, with some small room for growth in features
(spliterators) and test coverage.

> I noticed that you have, apparently in vain, attempted to contribute to
> upstream ... in
> an ideal world, that guy, whoever he is, should just make you a
> committer on that repo, but I'm guessing from seeing PRs here
> ignore
> that's not going to happen? ;-)

Completely unresponsive for 18+ months.

> But so instead of a new top level ODL project how about just:
> (a) just keep this on your personal GitHub, release to Maven central,
> and depend on it in yangtools? This code is for a very general data
> structure, and has nothing at all to do with ODL SDN as such.

Well, I really like to keep ODL coding standards and packaging, which
means consuming odlparent -- which is not in maven central, making it
not really convenient.

> (b) just integrate this either as a new package in an existing bundle or
> as a new bundle into an existing ODL project instead of creating yet
> another one?

As noted, this is already done, as the code currently lives in
yangtools. This works, but is not ideal, as it forces unnecessary
versioning churn.

> infrautils comes to mind - personally that's what I think
> it's for (general infra structure "lower than" yangtools). I do
> understand you have some sort of reservations about infrautils, but you
> are a commmitter on it, so you are more than welcome to contribute
> whatever you think is needed in infrautils to make it suitable for
> consumption e.g. by yangtools.

Not "some sort", I have voiced my reservations very clearly multiple
times. One key factor is no bounds on scope, which is very critical for
long-term project health -- at some point a project needs to become code
complete. There is no amount of code I can contribute to fix that.

Aside from that, the codebase in question is about 40% the size of
infrautils and it has *way* better quality:



> Just my 2 cents. If others feel strongly in favour of starting to have
> many "micro" projects at the top-level in ODL, then I have no strong
> objections against that either. But then we could start doing that for
> many other bunch of 5 classes as well...

Aside from '5 classes'. I personally have no problem with that -- as
long as you can:

and that is probably the real Q here - do we want to have such "small" projects.. I'll let others make that decision!
- clearly define scope and stick to it, quickly converging on
- provide strictly semver'd releases
- sit outside of autorelease


TSC mailing list


Join { to automatically receive all group messages.