>> 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/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 _______________________________________________ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
