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

[Thomas Monjalon <thomas@monjalon.net>]

25/05/2020 16:28, Burakov, Anatoly:
> On 25-May-20 1:53 PM, Thomas Monjalon 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.
> 
> I have more experience with Gitlab than Github, but i really don't see 
> it that way.
> 
> For one, reviewing in Gitlab makes it easier to see context in which 
> changes appear. I mean, obviously, you can download the patch, apply it, 
> and then do whatever you want with it in your editor/IDE, but it's just 
> so much faster to do it right in the browser. Reviewing things with 
> proper syntax highlighting and side-by-side diff with an option to see 
> more context really makes a huge difference and is that much faster.

OK


> I would also vehemently disagree with the "clarity" argument. There is 
> enforced minimum standard of clarity of discussion in a tool such as 
> Gitlab. I'm sure you noticed that some people top-post, some 
> bottom-post. Some will remove extraneous lines of patches while some 
> will leave on comment in a 10K line patch and leave the rest as is, in 
> quotes. Some people do weird quoting where they don't actually quote but 
> just copy text verbatim, making it hard to determine where the quote 
> starts. If the thread is long enough, you'd see the same text quoted 
> over and over and over. All of that is not a problem within a single 
> patch email, but it adds up to lots of wasted time on all sides.

Yes

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.


> And all of the above will not be a problem with a tool like 
> Gitlab/Github. There are "general" comments that can be used for general 
> discussion, and there are line-specific comments that can be used to 
> discuss certain sections of the patch. I've done this many times in many 
> reviews, and it works very well. Now, granted, I've never maintained an 
> entire repository like DPDK, so you may have a different perspective, 
> but i really don't see how long email chains have "clarity" that a 
> discussion thread with proper quoting, links to code, markdown syntax, 
> etc. doesn't.

You don't have discussion threading in GitHub. Is there?


> (for the record, i don't consider Gerrit to be a good tool because it 
> enforces a particular git workflow, one that is not at all compatible 
> with how our community works. GitLab, on the other hand, "just works" - 
> i'm assuming GitHub is very similar)
> 
> > 
> > There is a mailing list discussing workflow tooling:
> > 	https://lore.kernel.org/workflows/