Re: MacPorts Statistics
On Mar 28, 2014, at 7:03 PM, Craig Treleaven wrote: > Branching the subject a little, perhaps, but... > > Looking at the statistics page for a particular port, say libpng: > > http://stats.macports.neverpanic.de/categories/22/ports/2455 > > This has a lot of information that a user might be interested in before > installing a port. Right now, the port search page on the web leads to the > Portfile, eg: > > https://trac.macports.org/browser/trunk/dports/graphics/libpng/Portfile > > which isn't the prettiest advertisement for a piece of software. > > To me, the web search should give the potential user enough information to > decide if whether to install the package or not. A rough draft would be: > > = > From Portfile: > -port/subport name (link to Portfile) > -categories > -version/revision > -long_description > -variants (list with descriptions) > -homepage (as link) > -license > -platforms > -supported_archs > -dependencies (as links to other port pages; bonus marks if it could > link to an rdeps graph!) > > From statistics: >> # reported installs > -requested/ last week, 1 month ago, 1 year ago > -installed as dependency / last week, 1 month ago, 1 year ago > -rank of reported installs, requested, last week: xxx of 18,312 > -link to page with more detailed statistics > > From buildbots or package server (if possible): >> Dates of most recent builds > -version built / Mavericks, Mtn Lion, Lion, Snow Leopard > Eg: > 1.2.3_4 yesterday yesterday failed unsupported > (indicator if unsuccessful, not supported on that OS) > = > > I don't know if the last section is even possible. Would likely require the > buildbots to update a database at the end of each build? > > Thoughts? I like the idea. I'm sure this is implied by your above text but it might be nice to have the build bots have mpstats installed by default to participate in the statistics. Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts Statistics
Branching the subject a little, perhaps, but... Looking at the statistics page for a particular port, say libpng: http://stats.macports.neverpanic.de/categories/22/ports/2455 This has a lot of information that a user might be interested in before installing a port. Right now, the port search page on the web leads to the Portfile, eg: https://trac.macports.org/browser/trunk/dports/graphics/libpng/Portfile which isn't the prettiest advertisement for a piece of software. To me, the web search should give the potential user enough information to decide if whether to install the package or not. A rough draft would be: = From Portfile: -port/subport name (link to Portfile) -categories -version/revision -long_description -variants (list with descriptions) -homepage (as link) -license -platforms -supported_archs -dependencies (as links to other port pages; bonus marks if it could link to an rdeps graph!) From statistics: # reported installs -requested/ last week, 1 month ago, 1 year ago -installed as dependency / last week, 1 month ago, 1 year ago -rank of reported installs, requested, last week: xxx of 18,312 -link to page with more detailed statistics From buildbots or package server (if possible): Dates of most recent builds -version built / Mavericks, Mtn Lion, Lion, Snow Leopard Eg: 1.2.3_4 yesterday yesterday failed unsupported (indicator if unsuccessful, not supported on that OS) = I don't know if the last section is even possible. Would likely require the buildbots to update a database at the end of each build? Thoughts? Craig ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts Statistics (was Re: usage numbers for macports vs. homebrew?)
On Mon, Mar 24, 2014 at 11:31 PM, Clemens Lang wrote: > 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. Ouch. I actually failed to notice that the whole discussion was taking place on the users mailing list. > 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 Thank you. >> 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. Depending on which names are allowed (I didn't check), MacPorts could add hardcoded prefix, so instead of /Library/LaunchDaemons/org.macports.mpstats.plist one could have something like /Library/LaunchDaemons/org.macports.opt_local.mpstats.plist /Library/LaunchDaemons/org.macports.Users_me_macports.mpstats.plist (One could still get conflicting names by installing MacPorts to prefix=/opt_local, but I guess there would be other similar problems related to that as well.) But that should then apply to all ports. > Speaking of which, it might also be worth submitting > default_prefix: [true, false]. Interesting idea. While it's not directly useful for port authors, it would indeed be nice to have. >> (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. We probably need a separate discussion for that. Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts Statistics (was Re: usage numbers for macports vs. homebrew?)
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:// 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: <= 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 w
