Re: [dpdk-dev] decision process to accept new libraries

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

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?