[dpdk-dev] decision process to accept new libraries

Bruce Richardson bruce.richardson at intel.com
Tue Feb 21 14:46:59 CET 2017


On Fri, Feb 17, 2017 at 12:16:59PM +0100, Thomas Monjalon wrote:
> 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.
> 

I've just posted a patch to add this to our contributor guide doc.
Please review and comment.

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

That sounds a reasonable starting point. Are you suggesting that each
library go in a separate repo, or that we have a common staging area
repo for all new libs?

> 
> 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.
> 
I always think that removing things should be harder than adding, so I
have a couple of concerns here.
* Having "a public request with enough discussion" seems a rather
  tenuous threshold for a library to be faced with removal. Should some
  more measurable metric be used instead? For example,
  - lack of a responsive maintainer for 2 release cycles
  - high-priority bug (that severely limits the usefulness of the
    library), open for one release cycle.
  - request of maintainer (in case anyone voluntarily wants their code
    removed)
* I think for removal we might want to consider needing more than a
  majority of the tech board. Majority +1 or something perhaps?

> 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.
> 
The third one is the one I would query. I would view that as an
impossible goal to meet. If a significant subset of the community has an
interest in something, that is surely enough reason to have it in the
project.
One link of relevance to this discussion both in terms of scope and
removing things, is this case from the linux kernel:
http://news.softpedia.com/news/Linus-Tolvalds-Keeps-Code-in-the-Kernel-for-Just-One-User-470853.shtml


Regards,
/Bruce



More information about the dev mailing list