DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: "Thomas Monjalon" <thomas@monjalon.net>,
	"Morten Brørup" <mb@smartsharesystems.com>,
	"Jerin Jacob" <jerinjacobk@gmail.com>
Cc: dev@dpdk.org, techboard@dpdk.org,
	"Jim St. Leger" <jim.st.leger@intel.com>
Subject: Re: [dpdk-dev] Consider improving the DPDK contribution processes
Date: Mon, 25 May 2020 15:28:10 +0100	[thread overview]
Message-ID: <354a7cf6-788b-debf-1939-541410a1099b@intel.com> (raw)
In-Reply-To: <2346940.LZvDnYUUCF@thomas>

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/
> 
> 


-- 
Thanks,
Anatoly

  reply	other threads:[~2020-05-25 14:28 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-25  9:34 Morten Brørup
2020-05-25 11:00 ` Jerin Jacob
2020-05-25 11:12 ` Burakov, Anatoly
2020-05-25 11:58   ` Jerin Jacob
2020-05-25 12:53     ` Thomas Monjalon
2020-05-25 14:28       ` Burakov, Anatoly [this message]
2020-05-25 14:55         ` Wiles, Keith
2020-05-25 15:22         ` Thomas Monjalon
2020-05-25 15:35           ` Jerin Jacob
2020-05-25 15:52             ` [dpdk-dev] [dpdk-techboard] " Maxime Coquelin
2020-05-25 15:59               ` Burakov, Anatoly
2020-05-25 16:04                 ` Maxime Coquelin
2020-05-25 16:09                   ` Burakov, Anatoly
2020-05-25 16:28                     ` Thomas Monjalon
2020-05-25 16:57                       ` Wiles, Keith
2020-05-25 17:32                         ` Thomas Monjalon
2020-05-25 17:50                           ` Wiles, Keith
     [not found]                             ` <068c6367-b233-07f9-c038-4bddc4f48106@kth.se>
2020-05-26  9:33                               ` Burakov, Anatoly
2020-05-26 13:12                                 ` Wiles, Keith
2020-05-26 13:10                               ` Wiles, Keith
2020-05-25 18:44                       ` [dpdk-dev] [dpdk-techboard] Consider improving the DPDKcontribution processes Morten Brørup
2020-05-25 20:34                         ` Thomas Monjalon
2020-05-26  7:06                           ` Tom Barbette
2020-05-26  7:31                             ` Maxime Coquelin
2020-05-26  9:13                               ` Burakov, Anatoly
2020-05-26  9:43                         ` Burakov, Anatoly
2020-05-26 10:16                           ` Jerin Jacob
2020-05-26 10:33                             ` Thomas Monjalon
2020-05-26 10:52                               ` Burakov, Anatoly
2020-05-26 12:45                                 ` Thomas Monjalon
2020-05-26 13:57                                   ` Burakov, Anatoly
2020-05-26 14:01                                     ` Thomas Monjalon
2020-05-26 10:53                               ` Jerin Jacob
2020-05-25 16:01               ` [dpdk-dev] [dpdk-techboard] Consider improving the DPDK contribution processes Jerin Jacob
2020-05-25 15:43           ` [dpdk-dev] " Burakov, Anatoly
2020-05-25 14:55       ` Wiles, Keith
2020-05-25 12:08   ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
2020-05-25 15:04     ` Burakov, Anatoly
2020-05-25 15:28       ` Jerin Jacob
2020-05-25 15:47     ` Stephen Hemminger
2020-05-25 16:21       ` Bruce Richardson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=354a7cf6-788b-debf-1939-541410a1099b@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=jerinjacobk@gmail.com \
    --cc=jim.st.leger@intel.com \
    --cc=mb@smartsharesystems.com \
    --cc=techboard@dpdk.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).