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

[Finucane, Stephen]

> Stephen,
> 
> 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).

I'm all for the MVP approach: the best code is no code, after all. However, when you say tags, do you mean the tag infrastructure implemented in '3b8a61'? If so, how would you propose this would work? Personally I would imagine this needing new tags (i.e. 'Warning-by: xxx CI') but this would break one of the core tenants of patchwork: don't pollute the project's changelogs (ed: and mailing list) with patchwork poop. I could be wrong, so would it be possible to provide a sample workflow, similar to the one proposed by @ThomasMonjalon, for how you envision this?

> 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.

What kind of tags would you propose (i.e. what kind of classification is necessary)?

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

Yup, that's what I was going for :) I think CI by itself if a huge feature; I mean think of all the things it allows you to offload and automate: integration + unit testing, performance benchmarking, license validation, coding style...the list goes on. The requirement for automated (that bit's important), distributed testing is obvious for projects like DPDK (and also Open vSwitch, QEMU etc.). This proposal aims to plug this "gap" and no more. People may eventually find other uses for it, but as now I think it's useful enough by itself.

> Best regards,
> 
> Thomas