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

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.

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 18.02. 77% of them did not respond. 119 authors with at least 10 patches since 18.02 92 or 77% of them did not respond!!

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.

Survey Results – Email based review helpful? Out of the 27% 22% - Responses are slow 34% - Comments lost/not addressed Is email 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 emails is difficult - 44% 44% - Difficult to manage large list of emails

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

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.

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.

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.

Questions?