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 0B48034F3 for ; Fri, 1 Jun 2018 06:38:54 +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-0005mM-Pe for stable@dpdk.org; Fri, 01 Jun 2018 04:38:53 +0000 Received: by mail-oi0-f69.google.com with SMTP id j136-v6so2606534oih.13 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=tgI8gZjcygg/iL0g6Y/YeS0b3qclcoz64oV7pclZDr62WRpvCqN1mNWVW5xMbZvkZa sek3gaojuOqFLINvPXsL2RK6H1nY6Moh4JpF+5sNiareJWB76b38cl8Afn+4guIgSr7d lx6D0h3RftWaWmLtgh3nU6ydQ6ZnuOteiZwQvWCqTCGcgf98x4Y4J3fMK5Ecz5TFbGuG 7cjTqP1nOrAQCeSyovOmSsv+t3BF8EH+qBpfPkDu19rBuXCd5Ly1jFz2JOzTR7GnovCW z3mXGWSThrVUq5mQnAPNs9rb7DeiUhyRrK8nE//gqVowxOzE3EToHEVdZFgitPXsmIfa C5nQ== X-Gm-Message-State: APt69E2eA/sVpk/s5mZsleJlo9DAe8paFpGm5FRZUrRc0Iirt9Z7EQrh eSvsqDQPfsYXfiA0vVH/NkBHl5i6+P/b+sBm4KxJTwe6z361bvnA7xgyzabyYRdCPbvGMqkg+J2 tte96AmG6rEtP+YRs2h0KXXBWwciIwrI0Jap7tJpY X-Received: by 2002:a9d:2106:: with SMTP id i6-v6mr5919492otb.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-stable] Regression tests for stable releases from companies involved in DPDK X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 04:38:54 -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