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. My idea was not providing any data at all for packages that do not have DEP-8 tests. > 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. 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? > 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. -- Antonio Terceiro <terceiro@debian.org>
Attachment:
signature.asc
Description: Digital signature