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.
_______________________________________________
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
