Description and rationale

QA tasks happen “transparently” for the developers, i.e. without having to explicitly schedule them, in particular as a direct result of their “uploads” to Debian. Developers get notifications when the QA tasks uncover problems. Archive-wide results of QA tasks are provided in a machine-parseable way for easy external consumption. Depending on the specifics of each QA task, they are run regularly against existing packages or against newly uploaded packages.

This is key because automation of QA tasks is the only way to ensure consistent quality assurance over time, for all the packages, and for the entire spectrum of Debian contributors.

Developer perspective

This is about having automatic orchestration of building blocks defined in %STF M1: add QA tasks, for example “first build the package, then run QA tasks once build is done”, and can be implemented in parallel with %STF M1: add QA tasks. It is also about being able to schedule such tasks on all packages of a given distribution, maintaining a database of the results, and being able to feed them to the tracker.debian.org service.