[dpdk-dev] Notes from project governance meeting at DPDK Userspace

[Thomas Monjalon]

Thanks Dave for the good summary.
Some comments below.

2015-10-11 01:36, Dave Neary:
> Keith raised the issue of general throughput of patches, and the number
> of unreviewed/wait state patches: need to actively scale the process.
> 
> Stephen: How about identifying reviewers, and Thomas designates lead
> reviewer for each patch? Allows scaling of review, while allowing Thomas
> to have last word. Alternative proposals are to have joint "maintainers"
> all of whom can commit patches, subject to certain constraints (don't
> commit your own code), or subsystem maintainers, establishing a
> hierarchy of trust so that Thomas can just scan and accept reviews 90%
> of the time.
> 
> Thomas: Need many reviewers, but there should be one committer per tree.

Some maintainers are already identified in this file:
	http://dpdk.org/browse/dpdk/tree/MAINTAINERS
It is expected that the maintainers review every patches touching their
area (with exceptions for minor changes). They should also participate
in discussions to get consensus.
Reviews from non-maintainers are also very welcome.
Important features and fixes which are not properly reviewed should not
be integrated.
Someone in the room said it is the role of the patch author to get a
review. I agree.
Until now, patches from maintainers were accepted even if not reviewed.
Should it be changed?

In order to scale, some maintainers could become committers of a sub-tree.
The granularity of the sub-trees can evolve with growth of the project.
It seems a good idea to start with trees for drivers/net, drivers/crypto
and packet framework. It is not clear yet how EAL and core libraries can
benefit from any sub-tree.

> Chris: Do we have enough ppl with skills to be reviewers? If not, how do
> we get to that point?

Contributors must be motivated enough to get some time and, in some cases,
to get the green light from their management.
Some private discussions revealed that the lack of involvement is often due
to some management issues.

> Venky: Performance requires a specific skill set, not everyone has the
> skills, but slow patch review has an opportunity cost, and we can
> minimise cost of "bad" reviews with good CI performance tests that catch
> regressions

Yes having a good distributed CI will help. But it cannot replace reviews
for the quality and design considerations.

> How do we maintain review velocity when maintainer is unavailable (eg.
> on vacation)? How does it happen in Linux?
> 
> - Linus delegates - names "locum" maintainer while he is away. Stephen
> volunteered to do it for a week or two when necessary.

Thanks Stephen.

> Thomas: Subsystem maintainers carry review weight when maintainer is out.
> Stephen: Subsystem maintainers are reviewers, need high level of trust
> to be a top level maintainer.

Having a -next tree is another way of basing its work on an up-to-date tree
without waiting reviews.

> Thomas - Subtrees can live in DPDK git tree, makes it easier to manage
> merges afterwards. 2 volunteer subtree maintainers - Declan for crypto,
> Kevin for (not noted). Is it an issue if only Intel people are subtree
> maintainers? Venky: Yes, should have others.

About company sharing: it would be very nice to have more patches reviewed
by someone working for a different company than the author's one.
Considering making at least one review, when waiting for integration of its
patch, would be a good start.

>   - Some discussion around whether we should limit to one project per
> stack? Venky: Prefers not to
>   - Chris: How do decisions on new projects get made?

My understanding is that some new projects/layers can be added under the
dpdk.org umbrella. So different implementations of a DPDK layer will be
hosted in different dpdk.org git trees. But some implementations cannot
move there, e.g. ovs-dpdk.
What about https://01.org/spdk?
http://www.seastar-project.org?
https://github.com/rumpkernel/drv-netif-dpdk?
https://01.org/intel-data-plane-performance-demonstrators?

> We finished the discussion with a brief conversation on whether we
> should maintain certain branches for a long time.

1.8.0, 2.0.0, 2.1.0, the last digit can be used for stable branches.
 
> Bruce: Adds a lot of overhead
> Venky: Can do point releases on some branches
> Stephen: Prepared to "volunteer" someone from Brocade, because they need
> to maintain an older release anyway.

You just need to send me a SSH key and the version to maintain in order to
have a dedicated git tree.
Then the fixes should be preferably backported from the main tree.

Thanks everybody for the useful discussions.