[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#896023: Bug#901897 closed by Jonathan Nieder <jrnieder@gmail.com> (Bug#901897: fixed in git 1:2.18.0~rc2-2)

Hi Ian,

On 22-06-18 18:05, Ian Jackson wrote:
> AIUI what you are promposing is, when A's tests are being run for B's
> migration:
>  * tell autopkgtest to run the tests from A in testing, with an apt
>    configuration which pins B from unstable.
>  * autopkgtest runs an apt solver to install the to-be-tested
>    packages, including B from unstable and other things preferentially
>    from testing.
>  * if you are lucky, the to-be-tested packages include A from testing.
>    So you run A/testing's tests, with A/testing installed.
>  * if you are unlucky, the to-be-tested packages include A from
>    unstable.  Discard any test results so far, and restart:
>    this time, tell autopkgtest to run the tests from B in testing

A in unstable

> I think in principle this anomaly might occur for some .deb packages
> and not others.

It currently happens quite often, but often the test suite from testing
runs happily with the package from unstable. If the (passing) results
are of any value I can't say (E.g. transition with other source full
uploads (not uncommon), KDE stack, new python-defaults, ...)

So sure. The whole autopkgtest setup isn't perfect. In the perfect world
you would ask britney to calculate a migration. Run autopkgtest with the
"new testing", when no regressions occur, you're done and the migration
can happen. If there are, try again (what next?). This will slow down
the whole migration a lot because of the time it takes to test and the
amount of redos. So until we want to spend unlimited amounts of
computation resources, we have a limited situation anyways.

> And I think britney can migrate individual .debs
> occasionally ?

It does that all the time.

> This all seems quite a lot of workaround.  It would be
> better to treat britney as free software that we can modify to DTRT.

Yes, but it is more difficult there. Indeed, it is the Right Thing To
Do. It was in my summary email¹ as my second work item.

> But I'm not offering to do anh of the work so I will let you get on
> with your workaroud and wish you luck!

Thanks. As said, I think currently it is wiser to aim for good than for


¹ https://lists.debian.org/debian-release/2018/06/msg00239.html

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: