On 2013-12-28 15:02, Antonio Terceiro wrote: > On Fri, Dec 27, 2013 at 09:47:41PM +0100, Niels Thykier wrote: >> On 2013-12-27 21:08, Antonio Terceiro wrote: >>> Hi, >>> >>> On Thu, Dec 26, 2013 at 06:08:03PM +0100, Niels Thykier wrote: >>>> We are happy to use results from other automated tests (like >>>> autopkgtest [DEP8]) in the same way, as soon as someone runs them on >>>> the entire archive and gives us a machine-readable list of the >>>> results. >>>> >>>> [DEP8] http://dep.debian.net/deps/dep8/ >>> >>> I am playing with something for this. It's in a very initial stage, so >>> take it with a grain of salt: >>> >>> http://dep8.debian.net/ >>> >>> Please have a look at http://dep8.debian.net/data/packages.json and let >>> me know what other information you would need there. >>> >> >> Hi Antonio, >> >> Thanks for looking into it. At first glance, the exported json looks >> good! I am a bit curious on how we will distinguish a "has-no-tests" >> from a "not-tested-yet" case. >
Hi, Sorry, forgot to follow up on this. > My idea was not providing any data at all for packages that do not have > DEP-8 tests. > Okay, will packages then be in a "await testing"-state or so for packages with autopkgtest that are yet to be scheduled? >> Does your runner support retesting packages when a dependency is >> updated? E.g. if a new version of APT is uploaded, will it schedule the >> tests for python-apt (assuming the latter has DEP-8 tests)[1]? It is by >> no means a blocker, but I know there has been interest in the feature. > > That was actually one of my initial assumptions, so the runner was > designed around this feature. It will run tests for a package again when > there is a new version of the package or of any package in it dependency > chain. > Great. :) > One concern I have, though: reusing your example, suppose there are new > versions of both Python and APT, and python-apt tests break. How would > we know which of them is to blame? Will both of them be blocked from > migrating to testing? > I would say both, until we either get a manual judgement. Of course, if a future upload of one of the packages makes the problem go ahead, they can both be "unblamed" (provided that they are not blamed for another package). >> Before we can integrate it, we will probably need some way of fetching >> it securely (e.g. via https or ssh). > > no problem, it should be trivial to put https up. > Great. Looking forward to seeing this in action. :) ~Niels -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52d12930.2000...@thykier.net
