Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation

[Kent Fredric]

On Sun, 26 Apr 2020 10:08:32 +0200
Michał Górny <mgorny@g.o> wrote:

> A proper solution to cluster problem would probably involve some way to
> internally collect and combine data data before submission.  If you have
> large clusters of similar systems, I think you'd want to have all
> packages used on different systems reported as one entry.

For this, I'd suggest the ability to have an overrideable
"STATS_SERVER" (or something) ENV var URI that tells the submission
clients where to send their reports to.

Then have some server shipped in gentoo people can deploy, and submit
aggregated as a cron job, or potentially hand review the aggregated
submission data before submission, and potentially have tools to
whittle data out you don't want to share at the org level.

Such a tool is potentially useful to an organisation even without its
"submit to gentoo" capacity, as being able to internally analyse what
your organisation is using seems to be useful.

(eg: provide an admin a single point of information showing what
packages they need to audit, if all the nodes in the org are not
entirely controlled at the top level)

Though I think the overall design of anonymity by design is useful, I
can see usecases, especially in the organisation model, where being
able to voluntarily self-identify a node could be useful without
inherently being a privacy concern.

And you'd configure your relay to suppress these node identities in the
submitted data, or map them to a different org-wide identity. 

Example:
  I need to find somebody who is using <x> so I can ask them if <y>
  works, or if <z> is important to this package.

Example:
  Data indicates somebody within my org is using <x>, and I need to ask
  them not to use <x>, as its licensing terms are not compatible with
  our org.

Though for cases of voluntary identification, you'd need an interface
on the server node somewhere that allows you to generate unique ident
tokens, and associate data with them, possibly with a list of flags
dictating what records associated with this identity may be used for
(eg: Contact [y/n] )