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 `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
