GSoC 2019 [Collect build statistics]

Mojca Miklavec mojca at macports.org
Mon Mar 25 08:35:20 UTC 2019


Dear Fred,

(Resending due to the initial post from the wrong email account; sorry
for the duplicate.)

On Sun, 24 Mar 2019 at 22:57, Fred Wright wrote:
> On Sun, 24 Mar 2019, Mojca Miklavec wrote:
> > On Sat, 23 Mar 2019 at 17:49, Craig Treleaven wrote:
> >>
> >> I see no reason to report inactive ports.
> >
> > Neither do I. I would remove those as I already mentioned in an earlier email.
>
> But in the spirit of lossless collection, those should be included and
> flagged as inactive, so that what to do with them can be decided later.

Lossless collection is not about collecting our users' gender, age,
height, weight, shoe size, religion ... just in case that one might
want to study how MacPorts affects users' life, or what our
demographic is ... some time in the indefinite future.

I'm not saying that there is absolutely no use of inactive ports. What
I'm saying is that unless (or until) one can argue what we should use
that for, we should not submit that information at all.

There is a lot more other useful information that we are not
submitting at the moment, and could be useful. Like: how much time
passed since the last "port selfupdate / port sync / git pull &
portindex" run? When exactly did the use install or update the port
(to estimate the time passed between the actual commit and user
updating)?

Lossless collection is about not trying to discard data that you get
(with all the timing info etc.), and just storing some incomplete and
overly simplistic statistics that you have no way of fixing later.

> There are different reasons for inactive ports.  Sometimes they're just
> leftovers from upgrades without -u.

I never run upgrade with '-u' and only ever clean the leftover port
every few months, if at all. Literally everything in my inactive ports
is useless info.

> But sometimes the user is
> intentionally keeping inactive ports, to permit switching fairly quickly
> via activate/deactivate, either to keep multiple variants or to keep
> conflicting ports.

This would only be useful information if the inactive port info
actually came with the additional label about why the user kept that
other inactive port around.

> Speaking of return codes, it's not very helpful that "upgrade outdated"
> returns error status if nothing is outdated. :-)

Please file a ticket on Trac.

Mojca


More information about the macports-dev mailing list