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

Let autopkgtests be gating for testing migration in Buster: heads-up and brain-dump

Hi all,

On 12/21/16 21:13, Antonio Terceiro wrote:
> Sure. My main concern here is knowing exactly what the interface between
> britney and debci is going to be. Obviously we don't want a circular
> dependency, so it seems that you are going towards britney knowing how
> to deal with debci, and not the other way around.

In the end that is correct. But as you already state below, they need to
be aware of each other.

> On the debci side, we would need:
> - when testing to see if package X can be let into testing, britney
>   needs a way to say a) "test package X from unstable on a testing base"
>   and b) "test package Y from testing with X from unstable".
>   there would be one Y for each of the reverse dependencies of X, and
>   that list would be generated by britney, I assume.

Correct. Ubuntu uses the following syntax for that:
gedit {"triggers": ["glib2.0/2.20-1"]}
which means, run the gedit test suite with glib2.0 version 2.20-1 from
unstable. I believe the triggers field can contain multiple packages,
but I am not so much into that piece of code yet. Obviously the triggers
can also contain the package itself. For debci<->britney, I think
currently only testing as base is of interest.

> - a way for britney to "inject" these test requests, and a way for it to
>   get their results back. This would probably require having some sort
>   of identifier generated by britney that can be used by later to match
>   the request to the results.

When debci stores those "triggers" with the test result, britney would
be able to figure it out.

> Does that make sense?

Yes, and I hope I already answered the questions.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/autopkgtest-devel/attachments/20161221/1647bb79/attachment.sig>

Reply to: