2017-02-21 13:46, Bruce Richardson: > On Fri, Feb 17, 2017 at 12:16:59PM +0100, Thomas Monjalon wrote: > > 2017-02-17 10:22, Richardson, Bruce: > > > 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?
I suggest adding a new repo for each new lib or group some of them if relevant. Examples: dpdk-qos, dpdk-metrics, dpdk-extra-examples > > 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 agree with these criteria. I would like to add one more: - there are some maintenance work and is considered out of scope > * I think for removal we might want to consider needing more than a > majority of the tech board. Majority +1 or something perhaps? I think the technical board majority will take the right decisions. So I don't see a need to less consider this majority in some cases. > > 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. Yes I tend to agree. If a driver is useful for one user and there is not a lot more work to do on it, it deserves to be in DPDK. But we must avoid adding a small library or example which is at the scope border and grows so much that it becomes too important for the rest of 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 There is a big difference between Linux and DPDK: the first one is a kernel! There is no alternative for a monolithic kernel: it is in or out. In the DPDK case, we can host several libraries or examples in some separate repositories. The impact of having separate repositories is to reduce the work of a contributor touching many areas in a rework. This cost is transfered to the maintainer of the separate repository impacted by the change in the main repository. So it becomes this question: Do we prefer requiring some maintenance work from the contributors or from the maintainers?
