> On May 25, 2020, at 9:28 AM, Burakov, Anatoly <anatoly.bura...@intel.com> > wrote: > > 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. > > 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. > > 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. > > (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/ >
Bummer, I did not have to write my email, so +1000 to this one. > > -- > Thanks, > Anatoly
