<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Mar 8, 2019, at 9:45 AM, Arjun Salyan via macports-dev <<a href="mailto:macports-dev@lists.macports.org" class="">macports-dev@lists.macports.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class="">Thank you Mojca.<div class=""><br class=""></div><div class=""><font face="verdana, sans-serif" class="">The provided references have cleared a lot of my doubts and I am really interested to do this project: 'Collect build statistics'</font></div><div class=""><font face="verdana, sans-serif" class=""><br class=""></font></div><div class=""><font face="verdana, sans-serif" class="">Here is what I have understood so far:</font></div><div class=""><font face="verdana, sans-serif" class=""><b class="">1.</b> dynamic page for each port displaying basic information (description, version etc.), installation stats, build history etc.</font></div><div class=""><font face="verdana, sans-serif" class=""><b class="">2.</b> From suggested ideas, I found the following to be added to each page:</font></div><div class=""><ul style="font-family: Verdana, Arial, 'Bitstream Vera Sans', Helvetica, sans-serif; font-size: 13px;" class=""><li class="">whether the current version of port built on each particular OS/arch</li><li class="">when was the last time the port built on that OS/arch</li><li class="">links to all builds</li><li class="">list of installed files, differences in installed files on different OS versions</li><li class="">perhaps include some basic functionality to allow checking for build reproducibility</li><li class="">what is the latest version of port (in case it's already outdated)</li></ul><div class=""><font face="Verdana, Arial, Bitstream Vera Sans, Helvetica, sans-serif" class="">I do not understand : "</font><font face="verdana, sans-serif" class="">perhaps include some basic functionality to allow checking for build reproducibility".</font></div></div><div class=""><font face="verdana, sans-serif" class=""><br class=""></font></div><div class=""><font face="verdana, sans-serif" class=""><b class="">3.</b> I would further want to take up the task of migrating a redesigned website (or some components) into the same Django* app.</font></div><div class=""><font face="verdana, sans-serif" class=""><br class=""></font></div><div class=""><font face="verdana, sans-serif" class="">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)?</font></div></div></div></div></div></div></div></blockquote></div><div class=""><br class=""></div>Have you seen the following wiki page?<div class=""><br class=""><div class=""><a href="https://trac.macports.org/wiki/StatisticsIdeas" class="">https://trac.macports.org/wiki/StatisticsIdeas</a></div></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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. 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.</div><div class=""><br class=""></div><div class="">Craig</div><div class=""><br class=""></div><div class="">PS My mail archive show me that we’ve been talking about such a facility for more than 5 years! </div><div class=""><br class=""></div></body></html>