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 7865E2A5E for ; Tue, 21 Feb 2017 14:47:02 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Feb 2017 05:47:01 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,189,1484035200"; d="scan'208";a="1100604422" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.61]) by orsmga001.jf.intel.com with SMTP; 21 Feb 2017 05:46:59 -0800 Received: by (sSMTP sendmail emulation); Tue, 21 Feb 2017 13:46:59 +0000 Date: Tue, 21 Feb 2017 13:46:59 +0000 From: Bruce Richardson To: Thomas Monjalon Cc: dev@dpdk.org Message-ID: <20170221134658.GA208676@bricha3-MOBL3.ger.corp.intel.com> References: <59AF69C657FD0841A61C55336867B5B035B99794@IRSMSX103.ger.corp.intel.com> <3736276.ftqFo2Af7c@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3736276.ftqFo2Af7c@xps13> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.7.2 (2016-11-26) 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 13:47:03 -0000 On Fri, Feb 17, 2017 at 12:16:59PM +0100, Thomas Monjalon wrote: > 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. > I've just posted a patch to add this to our contributor guide doc. Please review and comment. > > 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? > > 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 think for removal we might want to consider needing more than a majority of the tech board. Majority +1 or something perhaps? > 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. 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 Regards, /Bruce