| 1 |
On Sun, 26 Apr 2020 03:39:24 -0700 |
| 2 |
Brian Dolbec <dolsen@g.o> wrote: |
| 3 |
|
| 4 |
> We would need that |
| 5 |
> person/team to only enable their test system for gentoostats/disabled |
| 6 |
> for deployments. Repeated failure to do that could result in that uuid |
| 7 |
> being blacklisted. Part of the initial profile details for that |
| 8 |
> vm/image would be some details about approx numbers of deployments |
| 9 |
> (yes, subject to change. But useful to know whether it is 10-15 or |
| 10 |
> 100-500. type of deployment ie: vm/docker/kubernetes/desktop/server... |
| 11 |
|
| 12 |
If the UUID generation was how I proposed in my other reply: On a |
| 13 |
voluntary basis, with ability for UUID's to have metadata about what |
| 14 |
the information associated with them may be used for, one could also |
| 15 |
have a metadata field indicating what /kind/ of user the UUID was |
| 16 |
associated with. |
| 17 |
|
| 18 |
Then people simply installing things for testing, and reporting results |
| 19 |
from their test rig could have a "tester" flag associated with a UUID |
| 20 |
used only for testing, and then we can exclude that data from the main |
| 21 |
reports, while still using it as evidence that a thing may work for |
| 22 |
some audience. |
| 23 |
|
| 24 |
The submission rate for UUID's with the "tester" flag could be allowed |
| 25 |
to be higher, because it no longer contributes to the overall |
| 26 |
statistics. |
Archives