[dpdk-dev] decision process to accept new libraries

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

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.

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

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.

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.