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

[Jerin Jacob <jerinjacobk@gmail.com>]

> I would add a third area: the process itself is arcane and inaccessible.
> The current consensus among the community seems to be that IRC + mailing
> list are "the most accessible" because "everyone has email" and "getting
> on IRC is easy".
>
> However, the truth is, they aren't "accessible", they are low tech, and
> thus *in*accessible to those who aren't veteran command-line Linux
> coders. No one uses IRC any more except OSS projects (so a new

I agree. Since IRC is not secure, a lot of companies are blocking the 6667 port.
Another alternative is to see _slack_ "free public" channels. Some of
the cool features of
new tools are really useful. like notification, search in chat
area(help to create the knowledge base),
mobile application support, tons of custom free apps for a specific
workflow, etc.

> contributor isn't likely to have an IRC set up unless they're already a
> habitual contributor to other projects), and 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.