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 260575A4E for ; Fri, 3 Jun 2016 17:08:24 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP; 03 Jun 2016 08:07:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,412,1459839600"; d="scan'208";a="713397085" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by FMSMGA003.fm.intel.com with ESMTP; 03 Jun 2016 08:07:51 -0700 Received: from irsmsx155.ger.corp.intel.com (163.33.192.3) by IRSMSX103.ger.corp.intel.com (163.33.3.157) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 3 Jun 2016 16:07:50 +0100 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.240]) by irsmsx155.ger.corp.intel.com ([169.254.14.34]) with mapi id 14.03.0248.002; Fri, 3 Jun 2016 16:07:50 +0100 From: "Mcnamara, John" To: dev CC: Christian Ehrhardt , Markos Chandras , Panu Matilainen Thread-Topic: RFC: DPDK Long Term Support Thread-Index: AdG9qZjkO0DgyHDnRPC8xMkMMP+0dQ== Date: Fri, 3 Jun 2016 15:07:49 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZWU4MTAyNmMtMmNmZi00NzNjLWFmMTUtNzcyYjE5YTgxNWMwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Im9iT25tQTNYamR4eVpyYTZSa1dnNXZyMk90ZkpjckhjTDdYdFFNTEdpM3M9In0= x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dpdk-dev] RFC: DPDK Long Term Support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 15:08:25 -0000 Introduction ------------ This document sets out a proposal for a DPDK Long Term Support release (LTS= ). The purpose of the DPDK LTS will be to maintain a stable release of DPDK wi= th backported bug fixes over an extended period of time. This will provide downstream consumers of DPDK with a stable target on which to base applications or packages. As with previous DPDK guidelines this proposal is open for discussion withi= n the community. The consensus view will be included in the DPDK documentatio= n as a guideline. LTS Maintainer -------------- The proposed maintainer for the LTS is Yuanhan Liu . LTS Duration ------------ The proposed duration of the LTS support is 2 years. There will only be one LTS branch being maintained at any time. At the end = of the 2 year cycle the maintenance on the previous LTS will be wound down. LTS Version ------------ The proposed initial LTS version will be DPDK 16.07. The next versions, bas= ed on a 2 year cycle, will be DPDK 18.08, 20.08, etc. What changes should be backported --------------------------------- * Bug fixes that don't break the ABI. What changes should not be backported ------------------------------------- * API or ABI breaking changes. * Features should not be backported. Unless: * There is a justifiable use case (for example a new PMD). * The change is non-invasive. * The work of preparing the backport is done by the proposer. * There is support within the community. Role of the maintainer ---------------------- * The maintainer will evaluate fixes to the DPDK master submitted by the fixing developer and apply them to the LTS branch/tree. * The maintainer will evaluate backported patches from downstream consumers and apply them to the LTS branch/tree. * The maintainer will not backport non-trivial fixes without assistance fro= m the downstream consumers or requester. Role of the downstream consumers -------------------------------- Developers submitting fixes to the mainline should also CC the maintainer s= o that they can evaluate the patch. A email address could b= e provided for this so that it can be included as a CC in the commit messages and documented in the Code Contribution Guidelines. The downstream consumers (OSVs and DPDK dependent application and framework developers) should identify issues in the field that have been fixed in the mainline release and report them to the maintainer. They should, ideally, assist with backporting any required fixes. Testing ------- Intel will provide validation engineers to test the LTS branch/tree. Tested releases can be marked using a Git tag with an incremented revision number.= For example: 16.07.00_LTS -> 16.07.01_LTS. The testing cadence should be quarte= rly but will be best effort only and dependent on available resources. Validated OSes -------------- In order to reduce the testing effort the number of OSes which will be officially validated should be as small as possible. The proposal is that t= he following long term OSes are used for validation: (OSV reps please confirm.) * Ubuntu 16.04 LTS * RHEL 7.3 * SuSE 11 SP4 or 12 * FreeBSD 10.3 Fixes for newer OSes, kernels (and associated KNI fixes), and newer GCC/Cla= ng versions can be backported but the validation effort will be limited to the above platforms. Release Notes ------------- The LTS release notes should be updated to include a section with backporte= d fixes. Patches for backporting should include additions to the release note= s like patches to the mainline branch. LTS Review ---------- The LTS guidelines shall be reviewed after 1 year to adjust for any experie= nces from LTS maintainership.