MacPorts Statistics (was Re: usage numbers for macports vs. homebrew?)

Mojca Miklavec mojca at macports.org
Mon Mar 24 14:02:22 PDT 2014


Hi,

First of all, I would like to express my gratitude to Clemens for
getting this project up and running. I really like the website. There
is definitely a lot that can be improved, but it's already really nice
as it is now.

It would probably make sense to discuss and collect different ideas
somewhere (it could be Trac, but it's probably suboptimal at this
early stage of brainstorming where lots and lots of ideas could be
discussed, prioritized, written down, ...).

Below I have written down a few issues that would probably be nice to
fix before the release of 2.30 (= before encouraging more people to
install and submit statistics).

- Would it be possible to configure Clemens' server/DNS to use
something like http(s)://stats.macports.org even if it's not hosted on
Apple servers?

- When the user upgrades to 2.3.0 (or installs MacPorts from scratch),
it would be nice to show a short notice saying something like "You are
welcome to participate in anonymous collection of statistics of
installed ports by running 'sudo port install mpstats'. See
http://<url> for more details." So that every user would see the
notice once for each major upgrade. (No notice if mpstats is already
activated.)

Some suggestions for changes in the format of file that gets submitted
(optimally this should be done before a lot of people start submitting
statistics):

- Add a field stating the version of file. In case that the format
changes in future, it would be nice to still be able to handle
submissions from users running the older version of MacPorts.

- Add a field '"requested": true' for requested ports (even if the
application isn't yet able to display any useful statistics related to
that, it will be easier to change the app in the future than to
convince everyone to apply the fix).

- Variants are currently submitted as a plain string:
    "variants": "biosig + python27 +";
  it would be a lot cleaner to use a list instead:
    "variants": ["biosig", "python27"]

- I would remove "gcc_version" from submitted data (even though it
doesn't hurt, so it can just as well stay).

- The program submits:
    "os_arch": "i386",
    "build_arch": "x86_64",
  I don't know if it's just me, but what exactly is the point of
"os_arch"? It's interesting to distinguish between ppc/i386/x86_64;
but why is os_arch "i386" important?

- The program submits the OS X version as 10.7/10.8/10.9. Are there
cases when having the patch level available would be useful? (I don't
think so, but I'm asking just in case.)


Just curious: if the user has two separate MacPorts installations and
installs mpstats on both – that would submit the statistics under two
different IDs, right?

I'm against publishing the database on any public place, but given
that "uuidgen" generates unique and non-reproducible numbers that
cannot be linked to a specific computer in any way (unless Apple built
some backdoor into the command), I don't see a problem if "trusted
committers" interested in development of the stats app can get a dump
of the database. I didn't check it yet, but I guess that there are no
IPs stored in the database anyway (or at least it would make sense if
they weren't).

I would like to suggest to eventually (not necessary now) copy or
move/rename "branches/gsoc11-statistics" to something that makes more
sense now when GSOC 11 is over and the project lives.

(It would probably be nice if MacPorts would allow installing
dependencies to allow running the app locally without much hassle. The
app needs rails 3.2.)

Mojca


More information about the macports-users mailing list