broken DDPO by not-so-broken reproducible-tracker.json

[Stuart Prescott]

>> 2. revert to unstable, but filter out packages tagged
>>    captures_build_path and friends (DDPO/tracker will just show no data
>>    about those packages)
> 
> I read a really good book once that made a very convincing argument that
> dashboards and metrics become subtly undermined once you introduce
> exceptions or you make them even slightly opaque.

By way of contrast, warnings on my maintainer dashboard should be actionable 
by me or they are pure noise. Don't pester me to fix things that are outside 
my control such as toolchain issues. Dashboards become undermined when they 
contain piles of warnings that the users train themselves to ignore because 
they are mostly irrelevant and thereby end up missing things they should 
actually see.

I am currently in a situation where pretty much every package I work on is 
now not reproducible but I can do nothing about most of them. It takes me 
far too much effort to find out if they're not reproducible because of build 
paths (about which I can do nothing) or some other problem that I could 
potentially fix. The current outcome is that I'm ignoring the reproducible 
column entirely and I'm spending no time looking at reproducibility issues. 
It's just too painful. There are other things I can work on with a smaller 
activation barrier.

(There's also a 5th option -- include the build-path in the definition of 
the build environment in the same way as the version of the compiler and 
various other bits of the build environment are mandated. Then there's 
nothing to filter....)

cheers
Stuart

-- 
Stuart Prescott    http://www.nanonanonano.net/   stuart at nanonanonano.net
Debian Developer   http://www.debian.org/         stuart at debian.org
GPG fingerprint    90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7