Hi Martin, On 03-05-18 08:59, Martin Pitt wrote: > Hello Paul, > > Paul Gevers [2018-05-02 23:09 +0200]: >> tl;dr: migration from unstable to testing is influenced by the results >> of autopkgtest tests of your own package as well as those of your >> reverse dependencies. > > Many, many, many¹⁰ thanks for working on this and landing it at last! It's so > great to see reverse dependency CI landing in Debian at last. And thanks to you for helping me out, especially in the beginning. >> It is the intention that in the (far) future regressions will become >> blocking for migration, but until then the added age will probably be >> raised over time as a semi-block. > > Hopefully not that "far" out :) Once the thing stabilizes, I suppose it would > be better to not land known regressions automatically, but rather land them > through overrides. Maybe even discussing how maintainers themselves can do that > for their own packages, to "reset a previous PASS". Are you subscribed to debian-devel? I already explained there¹ how DDs/DMs can reset the baseline. Also, Debian really tries to prevent regressions in testing. I.e. when a failure has landed somehow (e.g. hinted or by time passing in the current system), then there will not be a regression anymore. Unlike Ubuntu that has a did-it-pass-ever-in-any-release strategy. What I am considering is how to handle the situations where multiple triggers are needed. Currently that doesn't work except for one of the RT (or me) manually scheduling tests with a set of packages from unstable with the right trigger. And this for each trigger as britney doesn't handle multiple triggers (= triggers with a space) specially yet. I wonder if this already works properly if the versions were properly tracked in the (Test) Depends. Paul ¹ https://lists.debian.org/debian-devel/2018/05/msg00061.html point #2
Attachment:
signature.asc
Description: OpenPGP digital signature