Re: F30: System-Wide Change proposal: DNF UUID

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



A few concerns/comments (inline):

> === The problem ===
> 
> * A. Currently, we can only count Fedora OS use by observing IP
> addresses. This is subject to undercounting due to NAT — and to
> overcounting due to short DHCP leases and laptops moving between work
> or school and home or coffee shop.

"Counts are estimates" is not necessarily a problem. Please explain why this is a problem. Also, why not use statistical modeling to try to improve the estimates based on these known behaviors?

> * B. We can count what releases are observed, but we can’t distinguish variants.

Distinguishing between variants is reasonable, I think.

> * C. We can’t count quickly because various logs are copied back to a
> central server and data is not consistent for several days.

Why is eventual consistency not sufficient? What's wrong with waiting several days? Why would better counting be so time-sensitive/urgent?

> === Constraints ===
> * The Fedora community cares about privacy and is adverse to tracking
> measures. We don't want to track; just count.

I think you mean "averse", and yes, I think you're right about privacy. Who is "we"? I don't think you're speaking for the entire Fedora community.

> * For this reason, we don’t want to use any identifier like
> /etc/machine-id which may be used for other purposes.
> * And, also for that reason, there needs to be a relatively easy way to opt out.

If this must happen, please make it opt-in. You can use the opt-in data as a sample set statistical model for the rest of the data (those who didn't opt-in), so you don't need to have many people opt-in.

At the very least, the installer should have a dedicated full screen page explaining the feature with the ability to opt-out. The opt-out should not be buried in a menu, or some post-install step. dnf system-upgrades should be opted-out by default.

> * We need to be able to distinguish between short-lived instances
> (like temporary containers or test machines) and actual installations.

I think you're using the word "need" here, when "want" is more accurate. Either way, why do you want/need to do this?

> * Being able to see how systems are upgraded over time might be
> interesting but isn’t as important as privacy concerns.

A lot of the reasoning for this proposal seems to be based on "interesting", which I agree isn't as important as privacy concerns. Perhaps this is just my opinion, but I don't think a case has adequately been made for getting more accurate counts of Fedora installs.

> == Benefit to Fedora ==
> 
> * Better metrics overall
> * Public stats page updated automatically
> * Better knowledge of relative use of different variants
> * Insight into Fedora's use in short-lived test systems and temporary
> containers vs. longer-term installations

It's not clear how these things benefit Fedora. Are they benefits for their own sake or do they serve some larger purpose? Who looks at these metrics or stats pages and needs them to be more accurate or more regularly/automatically updated? What benefit do these insights bring to the Fedora community?

> == Documentation ==
> Release notes need to be written, and documentation describing how to opt out.

Documentation would certainly be necessary, but not sufficient. A good (prominent) UI for opting out is needed, or make it opt-in.

--
Christopher
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux