Saagar Jha > On Mar 8, 2019, at 08:12, Craig Treleaven <ctrelea...@macports.org> wrote: > >> On Mar 8, 2019, at 9:45 AM, Arjun Salyan via macports-dev >> <macports-dev@lists.macports.org <mailto:macports-dev@lists.macports.org>> >> wrote: >> >> Thank you Mojca. >> >> The provided references have cleared a lot of my doubts and I am really >> interested to do this project: 'Collect build statistics' >> >> Here is what I have understood so far: >> 1. dynamic page for each port displaying basic information (description, >> version etc.), installation stats, build history etc. >> 2. From suggested ideas, I found the following to be added to each page: >> whether the current version of port built on each particular OS/arch >> when was the last time the port built on that OS/arch >> links to all builds >> list of installed files, differences in installed files on different OS >> versions >> perhaps include some basic functionality to allow checking for build >> reproducibility >> what is the latest version of port (in case it's already outdated) >> I do not understand : "perhaps include some basic functionality to allow >> checking for build reproducibility". >> >> 3. I would further want to take up the task of migrating a redesigned >> website (or some components) into the same Django* app. >> >> Please help me with that 'build reproducibility' point and also how do I >> plan from here (I know Django, but I am still learning about MacPorts)? > > > Have you seen the following wiki page? > > https://trac.macports.org/wiki/StatisticsIdeas > <https://trac.macports.org/wiki/StatisticsIdeas> > > There are some deficiencies in the current data collected. A key issue is > whether a port was requested or installed as a dependency. That then leads > to the need for a versioned API. Other data elements need a re-think. > > My interpretation is that some key MacPorts people had privacy concerns > related to collecting such information. As such, there was no appetite to > strongly encourage users to participate in submitting the data. In crude > terms, the “opt-out” v. “opt-in” question. I don’t know if that is now > changed or not. > > I fall firmly on the side that it is fair to ask users for such data as it > helps us to understand how MacPorts is used. That can then guide us, as > MacPorts contributors, into where to channel our available time. I note that > Homebrew collects such information and there does not seem to be much > resistance, if any.
This isn’t true at all. Homebrew’s introduction of this feature was vehemently contested, especially because it 1. introduced analytics without reasonable warning or communication with users 2. used a third party (Google Analytics) and 3. was opt-in by default. The debate was silenced by the core team, who locked the associated thread <https://github.com/Homebrew/brew/issues/142> on GitHub because they felt that the decision was not up for discussion. FWIW, while I am not opposed to MacPorts adding clearly communicated, opt-in, self-hosted analytics; I would be very strongly against doing this if any of these conditions was not met. Doubly so if the initial discussion to do this is made without users being able to provide input, triply if the feature stays largely unchanged even when users complain, and quadruply if this discussion is forcefully closed, unresolved, because “the feature has already shipped”. > I think relying on opt-in would mean poor data quality and that implementing > such a collection and reporting system is largely a waste of time. IMHO. > > Craig > > PS My mail archive show me that we’ve been talking about such a facility for > more than 5 years!
