Re: Dealing with ci.d.n for package regressions
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.
Reply to: