From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by dpdk.org (Postfix) with ESMTP id 7B3A598 for ; Tue, 21 Feb 2017 15:42:50 +0100 (CET) Received: by mail-wm0-f48.google.com with SMTP id r141so77362551wmg.1 for ; Tue, 21 Feb 2017 06:42:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=9w+oe/J8+uEXyJUryZm7gzJh1r7u68LgKvlbb4+4hYc=; b=bH7oNWzmVrlL/NLfQpYmuzisNSp4sLqAXKB0Q0kk/651hkeaW06wtVP+oUDlBC51B1 m8VSYUTFWY3WdeEU0O2X53etC7eEyfMlfOBtwcLNygl5nlTJhLDx/UJYyg6S1LjNiJv+ HmBholvy557DOVhP3NPdyY8OTTg8ytZ39k2fnufLREsBYDwYMqYrfHAruE+pmAfJPMXz HcBqK4ZipnMmVV27GLzDe6eK0uT3kt4KOkodMKhwMNQcRkSlbwDzQFrM4UNxPHdoSP00 L8qromV2yIt6ZBeHixeU461jxDrpQbgvjaYlkn219gUPLWy/5sEIb7l0Y8qNaf4NYoNn U/XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=9w+oe/J8+uEXyJUryZm7gzJh1r7u68LgKvlbb4+4hYc=; b=idDr4IqSJA6B39TkLuXjOdNE9KR8UT4HVxv6Bt9fPxNK4fMGErtpvbOgI3hEDnpUan k7vWDoqQkKY5fRVlQ0p134dxAuxTE7Wjn3zB+GQC7wfY+PUZDOu9iw1CQrFELvMa6ymq G/+O/5btEPuxIhA9sotFMpZJ7Ayy1yXitqlLtWSIcXshhEnKM3ePusuUl4g0bQQj+90+ UdFyHBxhZLEZDEPtFaagssHD0XAGcE5LFLpIXn6q4/hFXThqq7yCaJ/4vgvhzJ9UEB2H 2kQlzKuqNeyinEuX2MiRHSuuNPBdjOuI5U/ejeci1BhKptZ+iGkHTWVsB7Mq/PBHL1SY yxEw== X-Gm-Message-State: AMke39mUc6IC95vEogwTX+j9vmyM6J5gMfH+2ukdw4FkcJukJ347Nf49+VAOAsfwWKHlHHIn X-Received: by 10.28.232.90 with SMTP id f87mr24697939wmh.35.1487688169724; Tue, 21 Feb 2017 06:42:49 -0800 (PST) Received: from xps13.localnet (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id m188sm17749175wma.27.2017.02.21.06.42.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Feb 2017 06:42:49 -0800 (PST) From: Thomas Monjalon To: Bruce Richardson Cc: dev@dpdk.org Date: Tue, 21 Feb 2017 15:42:48 +0100 Message-ID: <1746585.AAhpvkiIzm@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20170221134658.GA208676@bricha3-MOBL3.ger.corp.intel.com> References: <59AF69C657FD0841A61C55336867B5B035B99794@IRSMSX103.ger.corp.intel.com> <3736276.ftqFo2Af7c@xps13> <20170221134658.GA208676@bricha3-MOBL3.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [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: Tue, 21 Feb 2017 14:42:50 -0000 2017-02-21 13:46, Bruce Richardson: > On Fri, Feb 17, 2017 at 12:16:59PM +0100, Thomas Monjalon wrote: > > 2017-02-17 10:22, Richardson, Bruce: > > > 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. > > That sounds a reasonable starting point. Are you suggesting that each > library go in a separate repo, or that we have a common staging area > repo for all new libs? I suggest adding a new repo for each new lib or group some of them if relevant. Examples: dpdk-qos, dpdk-metrics, dpdk-extra-examples > > 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. > > > I always think that removing things should be harder than adding, so I > have a couple of concerns here. > * Having "a public request with enough discussion" seems a rather > tenuous threshold for a library to be faced with removal. Should some > more measurable metric be used instead? For example, > - lack of a responsive maintainer for 2 release cycles > - high-priority bug (that severely limits the usefulness of the > library), open for one release cycle. > - request of maintainer (in case anyone voluntarily wants their code > removed) I agree with these criteria. I would like to add one more: - there are some maintenance work and is considered out of scope > * I think for removal we might want to consider needing more than a > majority of the tech board. Majority +1 or something perhaps? I think the technical board majority will take the right decisions. So I don't see a need to less consider this majority in some cases. > > 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. > > > The third one is the one I would query. I would view that as an > impossible goal to meet. If a significant subset of the community has an > interest in something, that is surely enough reason to have it in the > project. Yes I tend to agree. If a driver is useful for one user and there is not a lot more work to do on it, it deserves to be in DPDK. But we must avoid adding a small library or example which is at the scope border and grows so much that it becomes too important for the rest of the project. > One link of relevance to this discussion both in terms of scope and > removing things, is this case from the linux kernel: > http://news.softpedia.com/news/Linus-Tolvalds-Keeps-Code-in-the-Kernel-for-Just-One-User-470853.shtml There is a big difference between Linux and DPDK: the first one is a kernel! There is no alternative for a monolithic kernel: it is in or out. In the DPDK case, we can host several libraries or examples in some separate repositories. The impact of having separate repositories is to reduce the work of a contributor touching many areas in a rework. This cost is transfered to the maintainer of the separate repository impacted by the change in the main repository. So it becomes this question: Do we prefer requiring some maintenance work from the contributors or from the maintainers?