[PATCH 00/10] Add support for tests "statuses"

Thomas Petazzoni thomas.petazzoni at free-electrons.com
Wed Jul 29 19:53:50 AEST 2015


On Wed, 29 Jul 2015 09:58:38 +0100, Stephen Finucane wrote:
> This series introduces support for patch "statuses". These are results
> of tests and other automated checks executed on any given patch. Such
> tests and checks can range from unit tests and license validation to
> large integration and performance testing. These statuses can be
> provided by multiple users, thus allowing for a "distibuted test
> infrastructure".
> This feature requires a number of changes, such as new models and
> extensions to the templates. Some new "endpoints" are provided for the
> XML-RPC API along with a minimal extension to the 'pwclient'
> application. It is envisioned that both this application and the
> broader collection of scripts provided with patchwork will be expanded
> on by the community as required.
> This feature is entirely optional and can be ignored by users if so
> desired.

Rather than a concept of "status", wouldn't it be better to simply
associate "tags" to patches ?

For example, when a patch successfully passes CI, you add a given tag
to the patch, or when it fails CI, you add another tag. And the web
interface would allow to filter the patches depending on which tag they
contain (or not).

Having tags would also be useful to associate other metadata to
patches, for example for which release of the project the patch is
targeted. In Buildroot, we typically have a fairly large amount of
pending patches, and it would be useful to be able to mark them by
various tags to classify them more easily.

The concept of "status" seems really tied to the CI need, and does not
address any other need.

Best regards,

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering

More information about the Patchwork mailing list