Paul Gevers writes ("Dealing with ci.d.n for package regressions"):
> As I just announced on d-d-a¹, we have enabled autopkgtest usage for
> unstable-to-testing migration.This is great. I have some suggestions/observations, looking particularly at https://release.debian.org/britney/update_excuses.html 1. Often the heading says Migration status: BLOCKED: Rejected/introduces a regression (please see below) I think that here "regression" does not mean an autopkgtest regression, but rather a new bug regression ? That couldwording coudl perhaps be clarified. 2. "Not considered" has always been a bit opaque for me. It often appears when many things have obviously been considered. What things are not considered ? 3. "Required age increased by 10 days because of autopkgtest" seems to appear when either (i) when there are tests that should be run but which haven't completed and (ii) when some tests newly failed ? I wasn't able to see any examples of the latter. 4. Can we have a way to trigger tests from updates of non-direct rdepends ? At some point in the future maybe we will run tests of whole batches of updates and then have some algorithm to chop out what the failures are caused by, but for now it would be useful to be able to declare a specific indirect dependency for test trigger. Maybe an XS- header field ? 5. AIUI there is no automatic way for the maintainers of the rdependency to be notified of a test failure which is blocking migration of one of their dependencies. Is that right ? The result is probably that if the maintainers of the dependency don't follow it up, the regression will migrate and the rdepenency maintainers will be left to fix it up. 6. This is really one for the wider project: as the blocking time increases, we are going to want some more relaxed rules for NMUing one of your rdependencies. (Right now that would be pointless since you'd upload it to DELAYED/10 and it would hardly migrate before your own timeout anyway.) Ian.
