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

[Clemens Lang]

Hi,

> 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, ...).

I think we can keep discussing things on the lists. I moved the
discussion to -dev and Bcc'd the -users list to keep anybody who wants
to follow up on this informed. This really is a -dev discussion and I
know some devs who hardly read -users.

I have created a wiki page I will update from time to time with good
ideas to prevent them from getting lost somewhere in the mail archive.
Feel free to edit the page, add your comments, etc:
  https://trac.macports.org/wiki/StatisticsIdeas

> 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).

First off: We don't have to deploy this immediately with the 2.3 release.
2.3 only ships the requirements to get this done, but we can still wait
a few weeks before committing the mpstats port.

> - 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?

Yeah, I consider this a necessity before deploying the system. I made
sure the config file that contains the URL is installed and can be
overwritten by the mpstats port, though.

> - 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.)

I think we should create a generic notification mechanism for that, e.g.
by putting files into trunk/dports/_messages/ with a header like:

<<EOF
---
require_confirmation: yes
requirements:
     macports::version >= 2.3.0
  && !port::installed(mpstats)
delay_until_reqs_fulfilled: yes
title: MacPorts now has statistics!
---
Put your text here
EOF

Then, after selfupdate, base should check for the existence of new files
(or re-evaluate unread messages that have delay_until_reqs_fulfilled set)
and display a message like
 ---> You have %d new messages. Run `port messages' to read them.
When `port messages' is run, it should display the messages one after
another (possibly using less(1)) and offer to mark them read. It should
also give a list of past messages.

> 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.

I agree.

> - 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).

I agree.

> - 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"]

Completely agree, too.

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

Yeah, that should be replaced with the version of the Command Line Tools.
We can get that using pkgutil --file-info /usr/bin/make

> - 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?

It's meant to show us the CPU architecture, but it should really
distinguish x86_64 and i386-only CPUs, because that information might
be helpful in the future.

> - 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.)

I don't think that's very useful, especially because we'd have to
re-aggregate the data in the web interface later.

> 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?

Yes. However, since mpstats requires a launchd plist, the installations
would probably conflict on the path of this plist. Suggestions to solve
this very welcome.
Speaking of which, it might also be worth submitting
  default_prefix: [true, false].

> 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).

Correct, the database doesn't contain any IPs.

> 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.

Yeah, that makes sense. Probably somewhere in contrib, where mpab and
other server stuff is.

> (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.)

I agree – if somebody would like to do some ruby porting, please go
ahead.

-- 
Clemens Lang