Re: [dpdk-dev] [PATCH v3 2/2] ethdev: add hierarchical scheduler API

[Thomas Monjalon <thomas.monjalon@6wind.com>]

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.