[OpenDaylight TSC] A new project proposal: TrieMap


Robert Varga
 

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


Michael Vorburger <vorburger@...>
 

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

 
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



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

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




--
Thanks
Anil


Robert Varga
 

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.

I am not sure what version bumping effort you are referring to -- the
project will not participate in autorelease and given its API/ABI
stability, downstreams can easily use ranged dependency, completely
eliminating the need for version bumping procedures known from SR.

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

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

Regards,
Robert


Sam Hague
 



On Thu, Sep 21, 2017 at 4:11 AM, Robert Varga <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?

I am not sure what version bumping effort you are referring to -- the
project will not participate in autorelease and given its API/ABI
stability, downstreams can easily use ranged dependency, completely
eliminating the need for version bumping procedures known from SR.

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

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. 

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.

Regards,
Robert


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



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


Sam Hague
 



On Thu, Sep 21, 2017 at 10:22 AM, Robert Varga <nite@...> wrote:
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?
No, this has not been done. I was suggesting that if we did want to rescope then we have an example and don't need to create a process. 

Regards,
Robert



Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES@Cisco) <vrpolak@...>
 

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,
The feature could be marked as a stable API [3].

But for being marked as Stable (with capital S) [2],
(among other things) Infrautils would need to be
Mature (as opposed to Incubation) project.

Vratko.

[2] https://wiki.opendaylight.org/view/Simultaneous_Release:Nitrogen_Release_Plan#Stable_and_Extended_Features
[3] https://wiki.opendaylight.org/view/Simultaneous_Release:Nitrogen_Release_Plan#APIs

-----Original Message-----
From: tsc-bounces@... [mailto:tsc-bounces@...] On Behalf Of Robert Varga
Sent: 21 September, 2017 16:22
To: Sam Hague <shague@...>
Cc: tsc@...; project-proposals@...
Subject: Re: [OpenDaylight TSC] A new project proposal: TrieMap

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