DPDK CI discussions
 help / color / mirror / Atom feed
From: "Xu, Qian Q" <qian.q.xu@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: "Liu, Yong" <yong.liu@intel.com>, "ci@dpdk.org" <ci@dpdk.org>
Subject: Re: [dpdk-ci] [dpdk-moving] proposal for DPDK CI improvement
Date: Mon, 7 Nov 2016 14:22:24 +0000	[thread overview]
Message-ID: <82F45D86ADE5454A95A89742C8D1410E3923C008@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <2991873.gcDsJIJtl2@xps13>

See below. 

-----Original Message-----
From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] 
Sent: Monday, November 7, 2016 8:51 PM
To: Xu, Qian Q <qian.q.xu@intel.com>
Cc: Liu, Yong <yong.liu@intel.com>; ci@dpdk.org
Subject: Re: [dpdk-moving] proposal for DPDK CI improvement

I'm removing the list moving@dpdk.org as we are discussing implementation details.

2016-11-07 12:20, Xu, Qian Q:
> > a). Currently, there is only " S/W/F for Success/Warning/Fail counters"
> > in tests, so does it refer to build test or functional test or 
> > performance test?
> 
> It can be any test, including performance ones.
> A major performance regression must be seen as a failed test. 
> 
> [Qian] If it refer to any test, so how do we know which test has been 
> done. For example, some patch may only do build, some may do perf and 
> some may do functional.
> How to differentiate these tests execution?   

Why do you want to differentiate them in patchwork?
There are 3 views of test reports:
1/ On a patchwork page listing patches, we see the counters S/W/F so we can give attention to patches having some warnings or failures.
2/ On a patchwork page showing only one patch, we see the list of tests, the results and the links to the reports.
3/ In a detailed report from the test-report ml archives, we can see exactly what's going wrong or what was tested successfully (and what are the numbers in case of a performance test).

---To differentiate the test(build, function and performance) that can give a clear view of what tests has been done, and what tests failed. And we don't need click 
the link to know which test failed. 
Now, all tests are sharing one column for the Pass or fail or warnings. For example, we see one patch Test failed, we don't know which test failed or even don't know if 
Which tests are executed. For example, if build failed, but no functional tests executed, then it showed as Failed; while if the build passed but one function test is failed, then 
It also showed as Failed. So from Failed, we don't know failures at which level tests. 
For one patch, I think we may have different requirements for build test, function test and performance test failures.  
To pass build is the 1st priority task, no errors are allowed. While as to functional tests, some failures on function may be acceptable if the pass rate is over 90% . As to 
the performance, the criteria for failure is not clear now, since performance will have some fluctuation and some features will bring some performance drop as the feature 
implementation cost. If we can't differentiate them, we can't easily judge the failure is really critical failures, and we even don't know which tests are executed.
Similarly, for a patch, we have Acked-by, Tested-by and Reviewed-by, which differentiate the different aspect of the patch review status. If we just put it as Pass or failed, how 
Can we know if it's reviewed failure or tested failure or acked failure? We even don't know which activity is done here. Even if there is a link to click see more details about 
Acted-by, Tested-by and Reviewed-by, it's not so convenient. So it's the similar thoughts to differentiate the tests. 

Btw, do you want to each patch have function and performance test? As we discussed before, currently we have 4 repos, then we may not sure if the patch should go to which repo, 
It's fine for the build, but for the function test, if it applied to wrong repo, then it may fail the tests. And we may need think how to solve the issue. 
In short term, I suggest that we only keep Build test for each patch, and run function and performance test on daily basis for the git tree. 

      reply	other threads:[~2016-11-07 14:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <86228AFD5BCD8E4EBFD2B90117B5E81E60310FA1@SHSMSX103.ccr.corp.intel.com>
     [not found] ` <3804736.OkjAMiHs6v@xps13>
     [not found]   ` <58200E0A.4010804@intel.com>
2016-11-07  9:59     ` Thomas Monjalon
2016-11-07 14:59       ` Liu, Yong
     [not found]   ` <82F45D86ADE5454A95A89742C8D1410E3923B784@shsmsx102.ccr.corp.intel.com>
2016-11-07 10:17     ` Thomas Monjalon
2016-11-07 10:26       ` Jerome Tollet (jtollet)
2016-11-07 10:34         ` O'Driscoll, Tim
2016-11-07 10:47           ` Arnon Warshavsky
2016-11-07 10:56           ` Thomas Monjalon
2016-11-07 12:20       ` Xu, Qian Q
2016-11-07 12:51         ` Thomas Monjalon
2016-11-07 14:22           ` Xu, Qian Q [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=82F45D86ADE5454A95A89742C8D1410E3923C008@shsmsx102.ccr.corp.intel.com \
    --to=qian.q.xu@intel.com \
    --cc=ci@dpdk.org \
    --cc=thomas.monjalon@6wind.com \
    --cc=yong.liu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).