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
>     https://wiki.opendaylight.org/view/Project_Proposals:Triemap
>     <https://wiki.opendaylight.org/view/Project_Proposals:Triemap>.
>
>     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
51

I was looking at https://github.com/romix/java-concurrent-hash-trie-map/tree/master/src/main/java/com/romix/scala/collection/concurrent - looks like there's a lot more than was there now.

 

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 https://github.com/romix/java-concurrent-hash-trie-map ... 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
> https://github.com/romix/java-concurrent-hash-trie-map/pulls 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:

infrautils:
https://sonar.opendaylight.org/overview?id=66717

triemap:
https://sonar.opendaylight.org/overview?id=org.opendaylight.yangtools%3Atriemap

> 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
feature-completeness
- provide strictly semver'd releases
- sit outside of autorelease

Regards,
Robert

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