Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: [gentoo-dev] [gentoostats continued] Collected data and justification for it
Date: Thu, 07 May 2020 07:29:48
1 Hi,
3 The previous thread covered a few topics, in this one I'd like to focus
4 on the data collected. So far people have indicated a few different
5 kinds of data they'd find useful. However, I don't think enough
6 attention has been put on explaining why they need the data and how
7 they'd use it.
9 I think we shouldn't collect any data unless we have a good plan on how
10 we'd be able to use it. In this thread, I'd like to collect ideas
11 on what data to collect and how it could realistically be used.
13 I'm going to start with the data and uses I can think of. Please reply
14 with other things you can think of.
17 1) list of selected packages (@world)
19 We would use this to determine the popularity of individual packages,
20 plus by scanning their dependencies we would be able to make combined
21 statistics for direct usage + dependencies of other selected packages.
22 This would allow us to judge which packages need more of our attention.
24 For example, as we port Python packages to Python 3.8 the packages with
25 more declared users would be ported first.
28 2) USE flags on installed packages (disabled/default/enabled)
30 This would allow us to determine which flags users are most likely to
31 actually rely on. This could determine tested flag combinations,
32 defaults, and required level of support for individual flags.
34 For example, if OCaml bindings on some package are broken and require
35 a lot of work, I would find useful to know how likely it is that anyone
36 is using it. Or if a lot of people are enabling 'frobnicate' flag,
37 I could consider employing USE defaults.
40 3) System profile
42 This would primarily allow us to establish how transition to new
43 profiles proceeds and could influence the decision on prolonging
44 the support for old ones. As a side effect, we'd have stats on how
45 popular different architectures are.
47 For example, it would help us see whether people are moving away from
48 amd64 17.0 to 17.1.
51 4) Arch - installed package correlation
53 This one could be considered a bit invasive but it would help us
54 determine how important is keeping particular arch keywords
55 on a package.
57 For example, package A breaks on SPARC. Fixing it would require
58 significant effort. If we know it has users on SPARC we're more likely
59 to put that effort; otherwise, we may just drop SPARC keywords and move
60 on.
63 That's all really useful stuff I can think of right now. What's your
64 angle?
66 --
67 Best regards,
68 Michał Górny


File name MIME type
signature.asc application/pgp-signature