From mboxrd@z Thu Jan 1 00:00:00 1970 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) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XpaB6q1QBsyIa2JeU4JPvGbacDcziD2IoQeZLJ3hpWU=; b=qGsZNYA2zQx+L54wdpL5YJmNCel2WMcGZcPNg4YVkWtefm5AmuzTSYoz77i48zBRZD UcCGVXkDSBHfWHVRuGsUPC7oE7/QEyJrFveDuRw2WM0hIzT3nusysvkluRufRJF1NPgA I8Hf6uEhPsgAjIaKUyRdEChMF9m325xhgI0Q17Tt+SnE21awoMxWJHl/BeqY+T9nWOtt fj+Z/etNRiNuqBspSYpNTUR/vBjGs+X1hveTQvP5vJqOs0RGjH2HbPdvpCobUSf9aRGV jPLJZRNtjvzhl+74/Aae2F8RTc1N1iFc9nNgf53qnUcQ5zZ3EV0qsQcpTvRxHymOY0rf 9HvQ== X-Gm-Message-State: APt69E3hrO071CxhjrL+VxBUwRJT0Pqab/U8X3GvXn43EMygu0/XTcVx 983y4fVloqrSYlw8t+8JwB5NV1A98X9Mt4hrqPdTL5UVNwRBy/W3VWkQMMcw22xvKBORqGUOylV HTYYLIot1/+9U3//shYuZViDV94XA7z6FE1u7 X-Received: by 2002:a9d:2106:: with SMTP id i6-v6mr5919491otb.222.1527827932526; Thu, 31 May 2018 21:38:52 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLlJiFNH4fUuEjvh+wRgxUpL4mvzzsUvntvAy2XU+VoLbOuN5LXGvE6YR4n4vQOs56hxwzeznbKdEhugc+UBx8= X-Received: by 2002:a9d:2106:: with SMTP id i6-v6mr5919486otb.222.1527827932390; Thu, 31 May 2018 21:38:52 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:3a87:0:0:0:0:0 with HTTP; Thu, 31 May 2018 21:38:21 -0700 (PDT) In-Reply-To: <1527762399.6997.44.camel@debian.org> References: <1527762399.6997.44.camel@debian.org> From: Christian Ehrhardt Date: Fri, 1 Jun 2018 06:38:21 +0200 Message-ID: To: Luca Boccassi Cc: dev , stable@dpdk.org, Thomas Monjalon Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [dpdk-stable] Regression tests for stable releases from companies involved in DPDK X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 04:38:53 -0000 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