From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id AE5766CA3; Thu, 31 May 2018 20:40:23 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 May 2018 11:40:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,463,1520924400"; d="scan'208";a="46308605" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga006.jf.intel.com with ESMTP; 31 May 2018 11:40:22 -0700 Received: from fmsmsx122.amr.corp.intel.com (10.18.125.37) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 31 May 2018 11:40:21 -0700 Received: from fmsmsx117.amr.corp.intel.com ([169.254.3.220]) by fmsmsx122.amr.corp.intel.com ([169.254.5.149]) with mapi id 14.03.0319.002; Thu, 31 May 2018 11:40:21 -0700 From: "Wiles, Keith" To: "dev-bounces@dpdk.org" CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] DPDK Release Status Meeting 31/05/2018 Thread-Index: AdP5Ay96krR7VY/ARw+9I/E4Ezlv6QARlCQA Date: Thu, 31 May 2018 18:40:21 +0000 Message-ID: <085852E3-7C21-4F2D-89EC-9C55FABB63A8@intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.100.81] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] DPDK Release Status Meeting 31/05/2018 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: Thu, 31 May 2018 18:40:25 -0000 > On May 31, 2018, at 12:18 PM, dev-bounces@dpdk.org wrote: >=20 > Minutes from the weekly DPDK Release Status Meeting. >=20 > The DPDK Release Status Meeting is intended for DPDK Committers to discus= s > the status of the master tree and sub-trees, and for project managers to > track progress or milestone dates. >=20 > The meeting occurs on Thursdays at 8:30 UTC. If you wish to attend just > send me and email and I will send you the invite. >=20 >=20 > Minutes 31 May 2018 >=20 > Agenda: >=20 > * DPDK 18.05 release. > * Retrospective on 18.05. > * Testing of stable releases. >=20 > Participants: >=20 > * Intel > * Cavium > * Mellanox > * NXP > * 6Wind > * RedHat >=20 >=20 > DPDK 18.05 release. >=20 > * DPDK 18.08 "The Venky Release" is out. \o/ > * Thanks to all the maintainers and contributors. > * See the release notes for the full stats: > http://dpdk.org/ml/archives/announce/2018-May/000204.html >=20 >=20 > Retrospective on 18.05. >=20 > * What went well. >=20 > * Largest DPDK release ever. > * Lots of contributors from all the main companies involved in networkin= g. > * Collaboration on major features between companies in the community. >=20 > * What didn't go so well. >=20 > * The release was very late and required a lot of release candidates. More testing is always better and sooner then later is better. > * RC1 was late and low quality. > * Many major defects found in RC testing. > * Some reviews were slow or late. >=20 > * What can we do differently next time. >=20 > * Should we change the number of releases per year from 4 to 3 or 2? > * Merge earlier from subtrees: every 7-10 days. Knowing when a merge is scheduled could help if say it would be every Monda= y or Wednesday. I would not put it on a Friday as that tends to cause peopl= e having to work on the weekends. Maybe every Wednesday would be best. It a= llows the developers to know when patches are applied and allow for more te= sting before the first RC. > * Push patches earlier. > * Review patches more critically. Does every feature/patch need to go in= . > * Use unit tests more > * Make them a requirement for any sizeable code. > * Make them easier to write/use/run. > * Add a make/meson target for generating coverage results from units > tests. Any volunteers? > * Hold more strictly to the release milestone dates. I notice at times developers need to rebase on to master because of changes= . Is this because of patches after theirs is applied before or do we need t= o have something in place to eliminate this rework? Knowing when someone is going to introduce a big patch that may disturb or = change many things effecting a patch would be nice to see a schedule produc= ed by the developer as to when it will be push. I hope it would give more c= ontrol for maintainers to schedule a given patch. >=20 >=20 > Testing of stable releases. >=20 > * Luca Boccassi asked about testing of the stable release. > * All major contributing companies should confirm test results on the sta= ble > releases. > * Luca will send an email to the list about it: > http://dpdk.org/ml/archives/dev/2018-May/103249.html >=20 Regards, Keith