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
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:
- clearly define scope and stick to it, quickly converging on
feature-completeness
- provide strictly semver'd releases
- sit outside of autorelease

Regards,
Robert