testing migration aging and reproducible builds

[Rebecca N. Palmer]

Chris Lamb wrote:> 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...

Would it be practical to temporarily turn off the check when this 
happens?  (And if it currently isn't, should that itself be considered a 
bug in britney?)

Jonathan Wiltshire wrote:
> How about if the current bonus of three days is dependent on both
> autopkgtests *and* reproducibility? That keeps the incentive without ending
> up with same-day migrations.

That would mean you get nothing for one if it isn't practical to have 
the other.  Maybe:
autopkgtest AND reproducible = 2 days
autopkgtest OR reproducible = 4 days
neither = 6 days
and if we decide to treat regression as worse than never having it:
unreproducible when was previously reproducible = 10 days
(Though I don't know if britney allows having more than 3 levels.)

Alternative option for regressions: indefinite block by default (so they 
can't get through unnoticed), but if you ask for an unblock when that's 
the only thing wrong, you get one (to 4-6 days as if it was never 
reproducible) no further questions asked.  (Given that one of the 
reasons for wanting reproducibility is security, maybe require this 
request to be signed, so a compromised buildd can't also fake it.) 
Though that might not be a good idea too early on, as if there are a lot 
of regressions it would be a lot of work.