[dpdk-dev] [dpdk-techboard] Consider improving the DPDK contribution processes

Wiles, Keith keith.wiles at intel.com
Mon May 25 18:57:04 CEST 2020



> On May 25, 2020, at 11:28 AM, Thomas Monjalon <thomas at monjalon.net> wrote:
> 
> 25/05/2020 18:09, Burakov, Anatoly:
>> On 25-May-20 5:04 PM, Maxime Coquelin wrote:
>>> On 5/25/20 5:59 PM, Burakov, Anatoly wrote:
>>>> On 25-May-20 4:52 PM, Maxime Coquelin wrote:
>>>>> On 5/25/20 5:35 PM, Jerin Jacob wrote:
>>>>>> On May 25, 2020 Thomas Monjalon wrote:
>>>>>>> My concern about clarity is the history of the discussion.
>>>>>>> When we post a new versions in GitHub, it's very hard to keep track
>>>>>>> of the history.
>>>>>>> As a maintainer, I need to see the history to understand what happened,
>>>>>>> what we are waiting for, and what should be merged.
>>>>>> 
>>>>>> IMO, The complete history is available per pull request URL.
>>>>>> I think, Github also email notification mechanism those to prefer to see
>>>>>> comments in the email too.
>>>>>> 
>>>>>> In addition to that, Bugzilla, patchwork, CI stuff all integrated into
>>>>>> one place.
>>>>>> I am quite impressed with vscode community collaboration.
>>>>>> https://github.com/Microsoft/vscode/pulls
>>>>> 
>>>>> Out of curiosity, just checked the git history and I'm not that
>>>>> impressed. For example last commit on the master branch:
>>>>> 
>>>>> https://github.com/microsoft/vscode/commit/2a4cecf3f2f72346d06990feeb7446b3915d6148
>>>>> 
>>>>> 
>>>>> Commit title: " Fix #98530 "
>>>>> Commit message empty, no explanation on what the patch is doing.
>>>>> 
>>>>> Then, let's check the the issue it is pointed to:
>>>>> https://github.com/microsoft/vscode/issues/98530
>>>>> 
>>>>> Issue is created 15 minutes before the patch is being merged. All that
>>>>> done by the same contributor, without any review.
>>>>> 
>>>> 
>>>> Just because they do it wrong doesn't mean we can't do it right :) This
>>>> says more about Microsoft's lack of process around VSCode than it does
>>>> about Github the tool.
>>>> 
>>> 
>>> True. I was just pointing out that is not the kind of process I would
>>> personally want to adopt.
>>> 
>> 
>> You won't find disagreement here, but this "process" is not due to the 
>> tool. You can just as well allow Thomas to merge stuff without any 
>> review because he has commit rights, no Github needed - and you would be 
>> faced with the same problem.
>> 
>> So, i don't think Jerin was suggesting that we degrade our merge/commit 
>> rules. Rather, the point was that (whatever you think of VSCode's 
>> review/merge process) there are a lot of pull requests and there is 
>> healthy community collaboration. I'm not saying we don't have that,
> 
> Yes, recent survey said the process was fine:
> 	http://mails.dpdk.org/archives/announce/2019-June/000268.html

IMO the survey is not a great tool for these types of things. The tech board and others that fully understand the process should decide. From my experience using Github or Gitlab is much easy and a single tool to submit patches to a project. Anatoly and others stated it very well and we should convert IMO, as I have always stated in the past.
> 
> 
>> obviously, but i have a suspicion that we'll get more of it if we lower 
>> the barrier for entry (not the barrier for merge!). I think there is a 
>> way to lower the secondary skill level needed to contribute to DPDK 
>> without lowering coding/merge standards with it.
> 
> About the barrier for entry, maybe it is not obvious because I don't
> communicate a lot about it, but please be aware that I (and other
> maintainers I think) are doing a lot of changes in newcomer patches
> to avoid asking them knowing the whole process from the beginning.
> Then frequent contributors get educated on the way.
> 
> I think the only real barrier we have is to sign the patch
> with a real name and send an email to right list.
> The ask for SoB real name is probably what started this thread
> in Morten's mind. And the SoB requirement will *never* change.
> 
> 

Would it not free up your time and energies by have the tools do most of the work. then you can focus on what matters the patch and developing more features? 

There is a reasons millions of developer use one of these two tools, instead of emailing patch around. We are a fairly small project compared to Linux Kernel and we are not developing code for the Linux kernel. Some of the process like coding standard is great, but the rest is just legacy IMO and not required to get the job done. Having tools to keep track of the minutia should free up more of your time for the real development.

Yes, it will be a learning curve for some and nailing down the process or rules for merge requests needs to be done.

All in all it will be a huge improvement for contributors.



More information about the dev mailing list