From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: decision process and DPDK scope Date: Thu, 09 Feb 2017 12:11:39 +0100 Message-ID: <1667864.GflPPoyiWF@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: techboard@dpdk.org To: dev@dpdk.org 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 891F4F947 for ; Thu, 9 Feb 2017 12:11:41 +0100 (CET) Received: by mail-wm0-f47.google.com with SMTP id v186so77191862wmd.0 for ; Thu, 09 Feb 2017 03:11:41 -0800 (PST) List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi all, When DPDK was a small project, it was easy to propose a major change, get feedback from the few contributors and figure a decision. It had the drawback of the lack of various point of views. So we probably made some quick and wrong decisions. As the community is growing, we need to improve the decision process to make sure the responsibilities are well shared and represent the diversity of the community. There has been a recent failure in this process. I would like to show it as an example of things to better solve. During last August, a patch was sent: "add bit-rate metrics to xstats". After more thoughts, a v2 was sent in October: "expanded statistic reporting". Starting from this version, the idea was to add completely new libraries. Nobody (including me) asked why we should maintain these things in DPDK. I have just realized that there was neither discussion on the need for these libraries nor on the DPDK scope. I feel the DPDK scope (and API in general) should be better owned by the community. So I took the decision to not integrate these patches in 17.02 and I'm sorry about that. It is a failure to not give good feedbacks on time. It is a failure to not ask the right questions. It is a failure to not have more attention on a new feature. It is a failure to take such decision alone. I think we can use this case to avoid seeing it again in the future. I suggest that the technical board should check whether every new proposed features are explained, discussed and approved enough in the community. If needed, the technical board meeting minutes will give some lights to the threads which require more attention. Before adding a new library or adding a major API, there should be some strong reviews which include discussing the DPDK scope. Openness of a large community is proven by its active feedbacks.