On Wed, Jul 29, 2015 at 12:14:54PM +0200, Thomas Monjalon wrote: > Hi Thomas, > > 2015-07-29 11:53, Thomas Petazzoni: > > 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). > > The goal is to have counters for Success/Warning/Failure as it is done > for A/R/T. > Note that A/R/T are not handled as tags because numbers are meaningful.
Yeah tags wouldn't be adequate, for many projects what's interesting is the count of failures and whether it's increasing or decreasing. :-) Simple tags wouldn't cut it. Bryce _______________________________________________ Patchwork mailing list [email protected] https://lists.ozlabs.org/listinfo/patchwork
