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.
