From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Ehrhardt Subject: Re: [dpdk-stable] Regression tests for stable releases from companies involved in DPDK Date: Fri, 1 Jun 2018 06:38:21 +0200 Message-ID: References: <1527762399.6997.44.camel@debian.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: dev , stable@dpdk.org, Thomas Monjalon To: Luca Boccassi Return-path: Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by dpdk.org (Postfix) with ESMTP id BB9B834F3 for ; Fri, 1 Jun 2018 06:38:53 +0200 (CEST) Received: from mail-oi0-f69.google.com ([209.85.218.69]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1fObq1-0005mJ-Fa for dev@dpdk.org; Fri, 01 Jun 2018 04:38:53 +0000 Received: by mail-oi0-f69.google.com with SMTP id u13-v6so13409517oif.0 for ; Thu, 31 May 2018 21:38:53 -0700 (PDT) In-Reply-To: <1527762399.6997.44.camel@debian.org> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, May 31, 2018 at 12:26 PM, Luca Boccassi wrote: > Hello all, > > At this morning's release meeting (minutes coming soon from John), we > briefly discussed the state of the regression testing for stable > releases and agreed we need to formalise the process. > > At the moment we have a firm commitment from Intel and Mellanox to test > all stable branches (and if I heard correctly from NXP as well? Please > confirm!). AT&T committed to run regressions on the 16.11 branch. > > Here's what we need in order to improve the quality of the stable > releases process: > > 1) More commitments to help from other companies involved in the DPDK > community. At the cost of re-stating the obvious, improving the quality > of stable releases is for everyone's benefit, as a lot of customers and > projects rely on the stable or LTS releases for their production > environments. > > 2) A formalised deadline - the current proposal is 10 days from the > "xx.yy patches review and test" email, which was just sent for 16.11. > For the involved companies, please let us know if 10 days is enough. In > terms of scheduling, this period will always start within a week from > the mainline final release. Again, the signal is the "xx.yy patches > review and test" appearing in the inbox, which will detail the > deadline. > > Hi Luca, I discussed with Thomas about it. I don't know how much extra effort for the stable maintainers it would be, but I wonder if there could be a XX.YY.z-rc tarball. That would be a) a more clear sign what people are used to test b) easier to integrate as I assume quite a bunch of tests will usually start rebasing on tarballs instead of directly from git. If you think everyone can derive from git easily I'm fine, I just wondered if a proper -rc tarball might be more comfortable for the testing entities. cu Christian