From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: [PATCH v3 2/2] ethdev: add hierarchical scheduler API
Date: Thu, 16 Mar 2017 19:10:53 +0100
Message-ID: <3089139.1r3dZqkNdq@xps13>
References: <1488589820-206947-1-git-send-email-cristian.dumitrescu@intel.com>
 <4544430.1vcQTJXfeh@xps13>
 <3EB4FA525960D640B5BDFFD6A3D891265276121D@IRSMSX108.ger.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: "O'Driscoll, Tim" <tim.odriscoll@intel.com>, dev@dpdk.org,
 jerin.jacob@caviumnetworks.com, balasubramanian.manoharan@cavium.com,
 "hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
 "shreyansh.jain@nxp.com" <shreyansh.jain@nxp.com>, "Wiles,
 Keith" <keith.wiles@intel.com>, "Richardson,
 Bruce" <bruce.richardson@intel.com>, techboard@dpdk.org
To: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>,
 konstantin.ananyev@intel.com
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49])
 by dpdk.org (Postfix) with ESMTP id BA57F1396
 for <dev@dpdk.org>; Thu, 16 Mar 2017 19:10:55 +0100 (CET)
Received: by mail-wm0-f49.google.com with SMTP id t189so54848483wmt.1
 for <dev@dpdk.org>; Thu, 16 Mar 2017 11:10:55 -0700 (PDT)
In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891265276121D@IRSMSX108.ger.corp.intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

2017-03-16 17:40, Dumitrescu, Cristian:
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > 2017-03-16 16:23, Dumitrescu, Cristian:
> > > ... <snip>
> > >
> > > > > Thomas, given Tim's confirmation of Intel's plans to implement this API
> > for
> > > > the ixgbe and i40e drivers in DPDK release 17.8, are you in favour of
> > including
> > > > this API in 17.5 with experimental tag (subject to full API agreement being
> > > > reached)?
> > > >
> > > > I think starting a branch in a dedicated "next" repo is a better approach.
> > > > rte_flow and eventdev were (and will be) integrated only when at least
> > one
> > > > hardware device is supported.
> > > > I suggest to follow the same workflow.
> > > >
> > >
> > > Thomas, if this is the only path forward you are willing to support, then let's
> > go this way, but let's make sure we are all on the same page with the terms
> > and conditions that apply.
> > >
> > > Do you agree now to merge this next-tree to DPDK once this API is
> > implemented for at least one PMD? We would like to avoid getting any last
> > minute objections from you or anybody else on the fundamentals; if you
> > have any, please let's discuss them now.
> > 
> > At least one "hardware" PMD, yes. It would prove the API can work for real.
> > About accepting it definitely in a given release, it will be checked
> > with the technical board on Monday.
> > 
> 
> OK, great, thank you. Is the agenda of the technical board meetings published in advance somewhere?

For the previous meeting, it was published:
	https://bimestriel.framapad.org/p/r.a5199d22813a5ac79d1d365b9cecb905
For the next one, please Konstantin, could you publish the agenda on a pad?

> > > How do we manage the API freeze on the next-tree? Once the API is
> > agreed, we would like to freeze it so the driver development can proceed;
> > we can then do some reasonably small changes to the API based on the
> > learnings we get during driver development. We would like to welcome any
> > parties interested in contributing to join Cavium, Intel and NXP in this effort,
> > but we would like to avoid any last minute major API change requests.
> > 
> > You are taking it the wrong way. Your main concern is to not be disturbed
> > with change requests. It should be the contrary: you have a chance to
> > work with other vendors to test and improve the API.
> > You should embrace this chance and delay the API freeze as much as
> > possible.
> 
> Not really. We definitely welcome change requests done in a timely manner. My concern is about last minute change requests, such as major API change requests just a few days before the release when driver development is complete. Is there a policy in place to prevent against such events for next-tree type of development?

No there is no such policy on a next- tree.
It is free to the maintainer of the tree I guess.