From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0CA83A04EF; Mon, 25 May 2020 17:35:50 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 694B51D6E9; Mon, 25 May 2020 17:35:49 +0200 (CEST) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) by dpdk.org (Postfix) with ESMTP id 1E9AE1D173; Mon, 25 May 2020 17:35:48 +0200 (CEST) Received: by mail-io1-f44.google.com with SMTP id c16so18966283iol.3; Mon, 25 May 2020 08:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=uawceRrx+DMZNy52RuzvQnxV0+Z4f1S85JhH7muEIZw=; b=uVR81KCJIrOTj+W6Rr5ij4V011iqa+K1j/SBY10WSiu4rrI7laMH4ScEsbHzaTh8iY y5e9acsgltllUDYPLhmJRxl0MVmCtdSqvsjnUBMLpaWngEP07rwgS2LxTsOw2Mm//Zx4 XLC5xvH+3QT4edC1/JCDRVCGmX+M1WfTsGto979tLWfopmCXCkzMlQLkYGMxiawWjmYy UEaZTnGUCC2OcKycGjhOf6CZ4Vn9Umep26QNTklQXWx6AfMAn/KvXgRXSMon+jPRZfIr DWYBQVn6A6ngaXmhV7mM/MiNQBITu1kOyoiAZGblc2e8smwxVHaqKixfmWHozSVr/Y5O zbpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=uawceRrx+DMZNy52RuzvQnxV0+Z4f1S85JhH7muEIZw=; b=rxh2dpXUVGSCXFgU60cPBmBxiu7zWbu6jgiAoNFR5hF3t3w6v8b7b+vl3jGfoXqeTC iqhd96qwnWB0ACPaxAiQ3LBnIOyGe2nNNp35RKTBRfLA4zPziadsfX6nLYjCVIhEShBc /e5NuJKzHD4Nm3fj70ThDvZ+39RQ4AXu5nCq3WVoYqRy2GuCUoNaGruYEnHoh0Ks9dUA BRaGus2dKacmHioIoIf2dsBtJdp+JgY8wx28sKBQSjhz6WjI1hyL3MF8rVRUmphYi4Ed d5iMGqxsegwsRgsc4SlsTR2YIbqJDaZGtEzPZ3o76jl1U7CXzOPfaIcyyKy+PBNGWKS4 NYZw== X-Gm-Message-State: AOAM532sycHW5dJf85vSPdAtnSxr3SXDu4ABbRDsNDBOGP3AQ2vcwQ2C Cx3k5JNzUqMqe69qj7bIkgrzVJ8WqIZObNRJY+0= X-Google-Smtp-Source: ABdhPJzA/s/8hxBURIp1lqQqanWxNavHuGkaqsvcO9bSqlBciI2cR84RztAH8B4JJBmQrPYEd0oqdnrHcT1YA0LuHQQ= X-Received: by 2002:a5e:8411:: with SMTP id h17mr13916045ioj.1.1590420947249; Mon, 25 May 2020 08:35:47 -0700 (PDT) MIME-Version: 1.0 References: <98CBD80474FA8B44BF855DF32C47DC35C60FEA@smartserver.smartshare.dk> <2346940.LZvDnYUUCF@thomas> <354a7cf6-788b-debf-1939-541410a1099b@intel.com> <3551245.iDPhyKTcbK@thomas> In-Reply-To: <3551245.iDPhyKTcbK@thomas> From: Jerin Jacob <jerinjacobk@gmail.com> Date: Mon, 25 May 2020 21:05:31 +0530 Message-ID: <CALBAE1MU-x5r_BtKs=ZTexd=MPbtZ5nOGeGdXT28y_s=E9a=sw@mail.gmail.com> To: Thomas Monjalon <thomas@monjalon.net> Cc: =?UTF-8?Q?Morten_Br=C3=B8rup?= <mb@smartsharesystems.com>, "Burakov, Anatoly" <anatoly.burakov@intel.com>, dpdk-dev <dev@dpdk.org>, techboard@dpdk.org, "Jim St. Leger" <jim.st.leger@intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] Consider improving the DPDK contribution processes X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> On Mon, May 25, 2020 at 8:52 PM Thomas Monjalon <thomas@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=C3=B8rup: > > >>> 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/G= itlab > > >>> for a while (we use those internally), going through DPDK mailing l= ist > > >>> and reviewing code over email fills me with existential dread, as t= he > > >>> process feels so manual and 19th century to me. > > >> > > >> Agree. I had a difference in opinion when I was not using those tool= s. > > >> 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 se= t > > >> 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 thr= eads. > > > GitHub reviews tend to be line-focused, messy and not discussion-frie= ndly. > > > 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 bu= t > > 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 genera= l > > 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 man= y > > 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/ > > >