On Wed, 1 Jul 2020 at 07:19, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > Yeah. I have no doubt that the decision was made carefully back then. > That said, time has passed, and btrfs has evolved and our use cases > have evolved too, so a fresh look is good. > > We have https://fedoraproject.org/wiki/Changes/DNF_Better_Counting, > maybe this could be used to collect some statistics about the fs type > too. > I am going to try and nix this one in the bud right here. DNF counting is NOT the place to do this. Starting to collect such information is a slippery slope and the more you collect the harder it is to remove personal identifiable data. If this sort of data is going to be collected it needs to be done by a specific program that does this, which can be audited, which can be deleted, and which can be 'cleaned' to meet GDPR and other rules. The DNF counting works because all it does is give a 'better guess' on what is going on by randomly burping a countme over a week (if countme is turned on). The data it collects in the end is not absolute but fuzzy.. it is just supposedly better a better fuzzy than the previous guesses. The other information gathered in that transaction is stuff that already has a business need to work.. our servers need to know what architecture, what release and what ip to send data the appropriate mirrorlist back to.. we also need to keep a log of the transaction to debug why XYZ proxy decided to send the wrong thing or some other issue. Mirrormanager does not have a need to know what filesystem you are using, it does not need to know what exact CPU, memory amount, or a bunch of other things which would be useful for the project. Even something like the packages you have installed which is sort of closely aligned with a business need that other distros do collect, it does not collect and adding it now would be a headache. If the project wants this, then someone needs to make a smolt replacement but with some people who truly understand privacy programming well enough to not end up with a landmine field. -- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
