On Mon, May 25, 2020 at 8:52 PM Thomas Monjalon <tho...@monjalon.net> wrote: > > 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.
IMO, The complete history is available per pull request URL. I think, Github also email notification mechanism those to prefer to see comments in the email too. In addition to that, Bugzilla, patchwork, CI stuff all integrated into one place. I am quite impressed with vscode community collaboration. https://github.com/Microsoft/vscode/pulls > > > > 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/ > > >
