Re: [dpdk-dev] decision process and DPDK scope

["O'Driscoll, Tim" <tim.odriscoll@intel.com>]

> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> 
> 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.

I assume you don't mean every new feature, just those that involve major changes (new libraries, new/modified APIs etc.). Is that correct?

> 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.

+1

At the moment, when there's no feedback on an RFC or patch set, there's no way of knowing whether that means people are happy with it or that nobody has reviewed it. Using the Tech Board to highlight RFCs/patch sets that require more review is a good idea.