From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) by dpdk.org (Postfix) with ESMTP id 9FBB92C37 for ; Thu, 2 Feb 2017 18:23:01 +0100 (CET) Received: by mail-wm0-f54.google.com with SMTP id b65so100437322wmf.0 for ; Thu, 02 Feb 2017 09:23:01 -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=LCaSu21Kf2HpfsfeLEUv3FbcGVDCd3r54GedNuIUwRg=; b=gaWycCE6wscyhmoE9a1N4n2dl7XUetWj9e91lafP5Cep0fkwF7bMMTr1EZvXNRlnzn d2Mrstd5Zm70AgMKQxt3TuhKACzmcBS5ZfhdeJJea13OZrkKjxbTkG7rYwjHE3EdC2pa IG+/R9A5ZPygXhS+UgeT4U3iMsZjKb7RbX4V4j1LMdENDkKKfLh+9CFICYjjTLzvZvuL RQbQNxmKsLxWlokVbV4fu0pL+CO/TtxaSyjDv8MrYQiDbSNR2iGjwp358W8SFOHDBpUU OIJdRawhLBtJI5gJaCeA6TEgvwYmmHjo7FrKFXJO5dnVixtlrPYAVlDmb9wiYq5vYlXG N9vA== 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=LCaSu21Kf2HpfsfeLEUv3FbcGVDCd3r54GedNuIUwRg=; b=ZZ+8KQxsfecaCTFN/qWUQOG+iQn0WxO8bfot+XSr75Y0IfLjDJEnd1hasf69apNNd6 YKPmlQF7JBnSzMFlwUNRMXZjoXrDRWmKalHu3BLbtQUVw3Cjs/q1zqYhIyxkUkN7Nbzo h2jA6D/ixaWrJ5V6fd5rZ+wzUzZ1e3+umn2sgQq7Df+hosPnWGoFiVP6nOp4zXSYYuDH kDSvU/c6N43M8iaBDFuCN1SKEd5wK29pqIMY1xVsXphpp4S5IxXfrzk4uHpHXeeA3lZq PB12Ev7sxza/6zS7J4JKkCfaYr6gIBVifr57ctC/2P97xiz4NIzyun32uR7pMMVv3oBl 2qMA== X-Gm-Message-State: AIkVDXIfWco8IFsAXoDLIUqkEazMoHaOS9EA8LjLTAqdoqvmhhDT7uOPGBTThXsFZ66a8GkY X-Received: by 10.28.30.12 with SMTP id e12mr9275726wme.125.1486056181273; Thu, 02 Feb 2017 09:23:01 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id d14sm36479957wmd.19.2017.02.02.09.23.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Feb 2017 09:23:00 -0800 (PST) From: Thomas Monjalon To: Bruce Richardson , "Mcnamara, John" , "Horton, Remy" Cc: dev@dpdk.org Date: Thu, 02 Feb 2017 18:22:59 +0100 Message-ID: <2532792.HP8aYUGVR2@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20170131132802.GA133984@bricha3-MOBL3.ger.corp.intel.com> References: <1484751943-22877-1-git-send-email-remy.horton@intel.com> <20170131132802.GA133984@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] [PATCH v9 1/7] lib: add information metrics library 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: Thu, 02 Feb 2017 17:23:01 -0000 2017-01-31 13:28, Bruce Richardson: > On Tue, Jan 31, 2017 at 01:13:11PM +0000, Mcnamara, John wrote: > > From: Thomas Monjalon > > > Hi Remy, > > > > > > > This patch adds a new information metric library that allows other > > > > modules to register named metrics and update their values. It is > > > > intended to be independent of ethdev, rather than mixing ethdev and > > > > non-ethdev information in xstats. > > > > > > I'm still not convinced by this library, and this introduction does not > > > help a lot. > > > > > > I would like to thanks Harry for the review of this series. > > > If we had more opinions or enthousiasm about this patch, it would be > > > easier to accept this new library and assert it is the way to go. > > > > Hi, > > > > The RFCs for this library (initially two, merged into one) have been up since October, during the 16.11 timeframe. Comments were made and applied. > > > > http://dpdk.org/ml/archives/dev/2016-October/049571.html > > http://dpdk.org/ml/archives/dev/2016-October/048390.html > > > > I'm concerned that these new comments/reservations are coming in very, very late in the 17.02 release cycle. > > > > If there hasn't been a lot of opinions or enthusiasm then equally there hasn't been other reservations. If there had been we would have addressed them. > > > > > > > It could be a matter of technical board discussion if we had a clear > > > explanation of the needs, the pros and cons of this design. > > > > We are happy to have the design discussed at the Technical Board. We would also like the inclusion of this library in RC3 to be discussed since that is still our desired outcome. > > > > We have, as any other company would have, customers awaiting features, developers committed to timelines, and testing and integration roadmaps. Blocking or delaying features at the last moment isn't an effective model that we, and I'm sure other companies, can work with. > > > > As such, it is probably best, that all current and future RFCs are reviewed at the Technical Board and that the board gives an indication on whether the proposal is acceptable for upstreaming or not. > > > > I would tend to agree with this. The tech board should indeed look to > insure that all RFCs and V1s have had some feedback on them well before > the merge deadline. > > I don't believe it's fair on developers to suddenly give feedback at > merge-time and thereby prevent the patch making it into a release, > without giving time to do any rework. This is especially true if the > patch had already been reviewed and acked, and so could be considered > "ready for merge". > > The tech board should also discuss some reasonable guidelines > for this area. My opinion is that by the time RC1 is released, any > patches that have been reviewed, acked and have no outstanding > comments on them for e.g. 1 week, must be merged in for the release. Any > additional feedback thereafter should be considered "too late", and > should be addressed in the following release. This will help to > incentivize reviewers to review early, and also give developers some > degree of confidence that their patches will be merged in. We have > deadlines for submitters to get patches in, we should also have > deadlines for reviewers to object to those patches. We are talking about adding some new libraries in DPDK. I think it is a special case where the submitter should make sure other contributors agree to add such new capabilities in DPDK. Saying there are some customers waiting for this feature to be upstreamed is not a good argument. But it could help to explain what the goal of this series. I agree this kind of comment should happen earlier and I'm sorry to not have explicit them in earlier stages. That's why I suggest the Technical Board could monitor this kind of proposal and make sure the discussion is progressing.