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 _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
