Re: [dpdk-dev] Consider improving the DPDK contribution processes

["Wiles, Keith" <keith.wiles@intel.com>]

> On May 25, 2020, at 7:53 AM, Thomas Monjalon <thomas@monjalon.net> wrote:
> 
> 25/05/2020 13:58, Jerin Jacob:
>> 25/05/2020 11:34, Morten Brørup:
>>> sending patches over an
>>> email as opposed to a well-integrated web interface workflow is so alien
>>> to most people that it definitely does discourage new contributions.
>>> 
>>> I understand the advantages of mailing lists (vendor independence,
>>> universal compatibility, etc.), but after doing reviews in Github/Gitlab
>>> for a while (we use those internally), going through DPDK mailing list
>>> and reviewing code over email fills me with existential dread, as the
>>> process feels so manual and 19th century to me.
>> 
>> Agree. I had a difference in opinion when I was not using those tools.
>> My perspective changed after using Github and Gerrit etc.
>> 
>> Github pull request and integrated public CI(Travis, Shippable ,
>> codecov) makes collaboration easy.
>> Currently, in patchwork, we can not assign a patch other than the set
>> of maintainers.
>> I think, it would help the review process if the more fine-grained
>> owner will be responsible for specific
>> patch set.
> 
> The more fine-grain is achieved with Cc in mail.
> But I understand not everybody knows/wants/can configure correctly
> an email client. Emails are not easy for everybody, I agree.
> 
> I use GitHub as well, and I really prefer the clarity of the mail threads.
> GitHub reviews tend to be line-focused, messy and not discussion-friendly.
> I think contribution quality would be worst if using GitHub.
> 
> There is a mailing list discussing workflow tooling:
> 	https://lore.kernel.org/workflows/

I disagree about GitHub/GitLab clarity the comments on the patch are inline with the code and these tools provide tracking of these comments. I believed GitHub/GitLab would help others contribute to DPDK easier and faster. With GitHub or GitLab it is a learning curve, but we do not need to have extra tools like patchwork it is already integrated into these tools. Submitting a patch should be simple and not require using N number of tools to submit a patch or manage a patch.

Being able to view the patches inline with code makes reviewing much easier and then being able to rebase the MR with a fixed approval method is great. These tools like any tools has it’s limits, but I think the advantage of these tools out weights some of the comments I have seen for using them.

Beginning able to track pretty much everything in one tool is great as it provides a much easier way to review patches and it focuses on the patch not looking up email messages to make a comment. We only need to comment via the tool at the exact location in the code. These tools also help track these comments and not have to figure out which of the N number of emails I need to respond too. Using the processes of the Linux kernel development is not the most user friendly method of development for developers IMHO.

Adding clang-format to commit-hook is a great way to keep the coding style going. It does not cover every case in DPDK, but they are minor IMHO. This means we can convert to one of these pre-canned formats and then adjust DPDK coding style.