1. DPDK Community Survey Results
Honnappa Nagarahalli, Arm
Maxime coquelin, REDHAT

2. Survey Changes to DPDK development process using GitHub, Gerrit
Discussion started after the 2018 North America Summit
2 Part Survey
Understand the pain points in the current process
Receive feedback on new tools/methods – contingent on the outcome of the first survey
Tech-Board and Volunteers helped deliberate the questions
Please remember that I am just a messenger.
Brief background on why the survey was done.
There have been discussions on changing the development process using GitHub, Gerrit etc. in the past. There was a question as well from the community in the 2018 North America Summit.
Tech-board decided to conduct a survey. It was decided to do a 2 part survey.
First part was to understand if we really have a problem with the current process. If yes, what are the pain points? It would have taken 10mns to answer all the questions.
The second part of the survey was intended to receive feedback on new tools/methods and was contingent on the outcome of the first survey.

3. Survey Response
1St Survey Sent out
Reminder Sent out
Deadline Extended
Advertised on VPP/SPDK
Even on Twitter!!
23rd Feb
1St Week
27 Responses
Deadline: 13th March
Extended Deadline: 23rd March
41 Responses
59 Responses!!
How was the response from the community?
This is not exactly an overwhelming response, remember that the survey was about what are the pain points.
There are about 119 authors with at least 10 patches since % of them did not respond.
119 authors with at least 10 patches since or 77% of them did not respond!!

4. Survey Results – Ease of sending Patches
Out of the 20%
58% said the process is too cumbersome
Somebody said ‘it is nerve wrecking’!!
We will go over some of the questions, starting with the key questions that define the outcome.
Out of the 20%, 58% said the process is too cumbersome, especially for infrequent contributors.
Somebody said it is nerve-wrecking to make sure nothing is missed. Something to take note and I think Travis CI helps one to make sure the patch is as per the guidelines.

5. Survey Results – Email based review helpful?
Out of the 27%
22% - Responses are slow
34% - Comments lost/not addressed
Is based review helpful?
73% said yes, 27% said no.
Out of the 27% ‘no responses’:
Slow responses - 22% 
Comments lost or not addressed - 34%
Managing the large list of s is difficult - 44%
44% - Difficult to manage large list of s

6. Survey Results – Is patchwork helpful?
Out of the 20%
Can’t link revisions
No way to get notified of patches under my maintainer-ship
Does patchwork help you in managing the patches?
80% say yes. 20% responded with issues.
Does not integrate with the process well. 
No way to link revisions of the patch, no way to get notified about patches under one’s maintainership, relies a lot on manual process (such as acks etc.), difficult to find one’s own patch (no direct link, need to search), hard to manage patch sets that have dependency.
It will be better if patchwork can automatically mark obsolete patch as superseded when new patch version is posted. Also, prefer to be able to leave and reply to comments online.
Hard to manage patch sets that have dependency

7. Survey Results – Other Questions
Do you find the coding guidelines easy to follow?
90% said yes, 10% indicated few issues
Ease of using the scripts in ‘devtools’
78% found it easy
22% said not easy (most pointed to difficulty in setting up checkpatch.sh)
Do you get enough reviews on the patches?
61% yes, 39% said no
Is the rate of response enough?
49% yes, 51% said no
The last 3 questions kind of decided the outcome of the survey. Few other questions worth mentioning are:
Some work for the community to address the review. I think reviews are never enough. But, here the majority seems to indicate concerns. Thomas’s release statistics helps encourage reviews, may be the member companies can help by asking their engineers to do more reviews.

8. The current process will not change
Conclusion
The current process will not change
The last 3 questions kind of decided the outcome of the survey. Few other questions worth mentioning are:
Some work for the community to address the review. I think reviews are never enough. But, here the majority seems to indicate concerns. Thomas’s release statistics helps encourage reviews, may be the member companies can help by asking their engineers to do more reviews.

9. But – Good Suggestions 26 unstructured comments were provided
Tech board is looking at incorporating some feedback
Advertise subtrees better
Elixir for DPDK
Process for integrating patches when maintainers do not respond
Not enough responses – Maintainers could delegate to others?
However, there were 26 unstructured comments. It also makes sense to implement some of the feedback provided in the survey questions which was unrelated to the process itself.
These were presented to the tech board and are being debated. Some are implemented already.
Address the ‘process for integrating patches when maintainers do not respond’ part. People have to maintain that code in their private repo.

10. Questions?