From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 473C239EA for ; Fri, 17 Feb 2017 12:17:01 +0100 (CET) Received: by mail-wm0-f47.google.com with SMTP id v77so7792262wmv.0 for ; Fri, 17 Feb 2017 03:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:user-agent:in-reply-to:references :mime-version:content-transfer-encoding; bh=AozDuT0El5GHPyXfNls61RIRJEfdBC42XIXGxxntp2U=; b=EjiiXZkwsQouDDV01tpPC40REJQc7wcQmlsuJnfx4HhNBZfLyTOunzLXOHZR0fYep1 2v9WMSbmvrN+eN4p9rtjnIuOeIs0HtzgBAoIWwTQJPtR2fhGi3fxayTEhzdIHYL+Opu+ lq4KcFAsmW82KR0Cd3HoIZeJ3m9iE5fa0+Y+vssduoqJER78NEueKCjl1Jlu+6RdS9eo qEXdO3ZFO4LFfCEpD7T+Ao4DzqPaPklYdvMoXfnhzz9gjvSS7eBZB+CgFO9MgqwOKvuV DdNAP2/IAxkK+QdH+8G8zjfuX8/CFF5RmFf3j7bQoQqfCS7rKcOiT8fNnNK5yAvyYvDx UqPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=AozDuT0El5GHPyXfNls61RIRJEfdBC42XIXGxxntp2U=; b=Nrhz//WfFYkcwfGU98xVFTNdg7oWRqhjH6Dlm5Axiyw5ivGuPrYSPg7aC6EzEYO9Cy SPTAXyQTMqqLTKu3EpMVbxVSwe7msQgTt7uDYf8OMeST0wdDm/FnXO4JiOS20d8frgnt rheaeoD98xVLXppnTjSHxxiSW4/znu0L4SdtAYSnyU9TiTFro4K3xMVfCX0hFpmDxdWo +2dxPBhIQtc+vzuTfnibw0sSEmvt8VNP+LUsQeOguiVMt7+LnNrh/YVNj6wlwPIZRYmX xsH23R2L1EaDs32FU0wynGhmEvr0Hts9p3Tz1TwuVf5cRy5YRDYvuqGWZc8DUUNuWQSn Vqdw== X-Gm-Message-State: AMke39meG4DVfbCC9Rioa/iOrFEEqGwgXAoGvunGTJC3Jj7eC6vb+R3WxjoS0czmJoeknd3t X-Received: by 10.28.55.68 with SMTP id e65mr1695270wma.62.1487330220830; Fri, 17 Feb 2017 03:17:00 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id w30sm12606822wrb.5.2017.02.17.03.17.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Feb 2017 03:17:00 -0800 (PST) From: Thomas Monjalon To: dev@dpdk.org Date: Fri, 17 Feb 2017 12:16:59 +0100 Message-ID: <3736276.ftqFo2Af7c@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <59AF69C657FD0841A61C55336867B5B035B99794@IRSMSX103.ger.corp.intel.com> References: <59AF69C657FD0841A61C55336867B5B035B99794@IRSMSX103.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: [dpdk-dev] decision process to accept new libraries 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, 17 Feb 2017 11:17:01 -0000 2017-02-17 10:22, Richardson, Bruce: > 4. Issue of review and timely feedback > * Discussion focused on review of patches for existing DPDK components/libraries > * Agreed that patch maintainers are primarily responsible for accepting patches in their area, and need to ensure sufficient reviews are done > * Once patch has been sufficiently reviewed, the maintainer should ack the patch > * Any patches which have been acked by the maintainer, and which have no subsequent issues raised with them, should be automatically merged to the relevant tree after 2 weeks. > - in case where the ack is received less than 2 weeks before a merge deadline, the point at which it can be automatically merged is 2 days before the deadline > - To make a release, a patch must be acked by the maintainer at least 2 days before the merge deadline. > * If not merged at the automatic-merge deadline itself, e.g. unavoidable delay by committer, any subsequent feedback received should be considered "too late", and must be addressed by a follow-on patch, rather than via a revision of the original submission. > * Trivial patches may be merged sooner, or without maintainer ack, at the tree committers discretion. That's really good to have more rules like the one above. It will make the process clearer to everyone, and hopefully will speed up our workflow. > 5. Accept and review new libraries > * Discussion begun on this topic, but no consensus reached before time ran out > * Most members felt this topic was closely tied to the "scope" of DPDK as a project > * Discussion to continue over email, and to be discussed at the next meeting if not resolved before then. Let's discuss this important topic. Deciding to add a library is about deciding the scope of the project. However I think we do not need to define the DPDK scope now, but we can define a process to help in scope decisions. It is a first step which will help us to progress later in scope discussions. Below are 3 separate (and related) topics to discuss. Please let's target a decision for the first item only. 1/ I suggest that each new library must be developed in a separate repository on dpdk.org. Then it can be asked to integrate it in the main project/repo. Such discussion must happen on the mailing list and the techboard will vote for the integration of the *existing* library. I suggest such vote should be done by majority as stated in the LF charter. 2/ We could imagine the same kind of process for removal, i.e. moving a library or an app outside of DPDK in a separate repository. If there is a public request with enough discussion, the techboard could vote for moving some DPDK parts in a separate repository. The committer would be a volunteer or the current maintainer of the code. A dedicated mailing-list will be created for the new project. 3/ Why a project scope should be defined? I think it is important to agree on the long-term goal of defining a scope. My view on the goal for the main DPDK project (git://dpdk.org/dpdk): - a consistent set of libraries - a good quality in every libraries - contributors interested in every libraries (no community segmentation) - contributors able to understand every libraries In less words, a clear project by a strong community of contributors.