testing migration aging and reproducible builds

[Chris Lamb]

Dear Ivo et al.,

Thanks for reaching out.

So, the devil is very much in the details here, alas. Whilst I am a
definite +1 on this idea the day-to-day experience may not be ideal
so your thoughts are very welcome.

Just to take one recent example: I noticed yesterday a regression
whereby one of our tools (strip-nondeterminism) is causing a fair
number of Java packages to be unreproducible — it would seem a little
antisocial to block them from migrating to testing when it was "our"
fault. It is not really within the power or remit of the maintainers
in-question to fix this particular issue, and we should not implicitly
encourage maintainers to manually (!) fix it in each of the affected
packages just to get it to migrate...

Similar mishaps or problems with the testing framework itself are
usually more typical than the above but would have the same effect of
directing a lot of distracting and demotivating blowback in our
direction.

Note that delaying migration here has quite a different consent
and social dynamic to autopkgtest failures as the maintainers have,
by uploading a package that contains autopkgtests, implicitly opted
into the committment to ensure they continue to pass.

Anyway, your thoughts on this important angle?

> For this to be possible, we would need to have an automated way to get 
> data about the source packages

Regarding the technical side of the implementation, we currently
generate this (~3MB bzipped) JSON file:

  https://tests.reproducible-builds.org/debian/reproducible.json.bz2

... that (unless I am mistaken) is the data being used by qa.debian.org.


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby at debian.org 🍥 chris-lamb.co.uk
       `-