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.
Paul
signature.asc
Description: OpenPGP digital signature
