From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 103B5A04A4; Tue, 26 May 2020 11:13:17 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 539301DA22; Tue, 26 May 2020 11:13:16 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 4657D1D667; Tue, 26 May 2020 11:13:14 +0200 (CEST) IronPort-SDR: ql1sCYXNQZm6s5lGwm1tZ3lVdEExFDxZ3jwOvb4HiwBp600cOfcO6QvZ2/tWMd51wsROIcT0zE i5QRveFNdiCQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 May 2020 02:13:13 -0700 IronPort-SDR: 312Pq3oJ76PFLKxtpTGBVpzzufTUpwhNNceGnhM899MgvrSzQBTPUPFwPjOXYk5x27RD7MaHWk QRX3raKiwXqg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,436,1583222400"; d="scan'208";a="375642463" Received: from krnacejr-mobl.amr.corp.intel.com (HELO [10.209.43.93]) ([10.209.43.93]) by fmsmga001.fm.intel.com with ESMTP; 26 May 2020 02:13:11 -0700 To: Maxime Coquelin , Tom Barbette , Thomas Monjalon , Jerin Jacob , =?UTF-8?Q?Morten_Br=c3=b8rup?= Cc: dpdk-dev , techboard@dpdk.org, "Jim St. Leger" References: <98CBD80474FA8B44BF855DF32C47DC35C60FEA@smartserver.smartshare.dk> <11959277.FkLDZFFinP@thomas> <98CBD80474FA8B44BF855DF32C47DC35C60FF5@smartserver.smartshare.dk> <1854859.fY831ScpFY@thomas> From: "Burakov, Anatoly" Message-ID: <3677dfe2-9fd7-ccaa-d96d-fc0918d11b93@intel.com> Date: Tue, 26 May 2020 10:13:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [dpdk-techboard] Consider improving the DPDKcontribution processes X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 26-May-20 8:31 AM, Maxime Coquelin wrote: > > > On 5/26/20 9:06 AM, Tom Barbette wrote: >> Le 25/05/2020 à 22:34, Thomas Monjalon a écrit : >>> 25/05/2020 20:44, Morten Brørup: >>>> From: Thomas Monjalon >>>>> 25/05/2020 18:09, Burakov, Anatoly: >>>>>> obviously, but i have a suspicion that we'll get more of it if we >>>>> lower >>>>>> the barrier for entry (not the barrier for merge!). I think there is >>>>> a >>>>>> way to lower the secondary skill level needed to contribute to DPDK >>>>>> without lowering coding/merge standards with it. >>>> >>>> That is exactly what I am asking for: Lowering the barrier and >>>> increasing the feeling of success for newcomers. (The barrier for >>>> merge is probably fine; I'll leave that discussion to the maintainers.) >>> >>> I understand. >>> >>> >>>>> About the barrier for entry, maybe it is not obvious because I don't >>>>> communicate a lot about it, but please be aware that I (and other >>>>> maintainers I think) are doing a lot of changes in newcomer patches >>>>> to avoid asking them knowing the whole process from the beginning. >>>>> Then frequent contributors get educated on the way. >>>> >>>> Great! I wish that every developer would think and behave this way. >>>> >>>>> >>>>> I think the only real barrier we have is to sign the patch >>>>> with a real name and send an email to right list. >>>>> The ask for SoB real name is probably what started this thread >>>>> in Morten's mind. And the SoB requirement will *never* change. >>>> >>>> The incorrect Signed-off-by might be the only hard barrier (which we >>>> cannot avoid). But that did not trigger me. >>>> >>>> I was raising the discussion to bring attention to soft barriers for >>>> contributors. What triggered me was the request to split the patch >>>> into multiple patches; a kind of feedback I have seen before. For an >>>> experienced git user, this is probably very easy, but for a git >>>> newbie (like myself), it basically means starting all over and trying >>>> to figure out the right set of git commands to do this, which can be >>>> perceived as a difficult task requiring a lot of effort. >>> >>> Yes I am aware about this difficulty. >>> It is basically knowing git-reset and git-add -p. >>> I agree a cookbook for this kind of thing is required. >>> >>> I would like to do the split for newcomers, >>> but we need also to validate the explanations of each commit. >>> A solution in such case is to send the split so the newbie can just >>> fill what is missing. >>> This kind of workflow is really what we should look at improving. >>> >>> >>>> Perhaps we could supplement the Contributor Guidelines with a set of >>>> cookbooks for different steps in the contribution process, so >>>> reviewers can be refer newcomers to the relevant of these as part of >>>> the feedback. Just like any professional customer support team has a >>>> set of canned answers ready for common customer issues. (Please note: >>>> I am not suggesting adding an AI/ML chat bot reviewer to the mailing >>>> list!) >>> >>> OK >>> >>> >>>> The amount of Contributor Guideline documentation is also a >>>> balance... it must be long enough to contain the relevant information >>>> to get going, but short enough for newcomers to bother reading it. >>> >>> Yes, we need short intros and long explanations when really needed. >>> It is touching another issue: we lack some documentation love. >>> >>> >> >> >> Maybe we could find something that allows to "git push" to the >> patchwork, where it kind of appears already as a github-like discussion? >>  It doesn't miss a lot to enable writing from the website directly >> (basically auto-email). >> >> Personnaly I've put a lot of efforts to fix simple comments, be sure >> that I wrote "v2" here, sign-off there, cc-ed the right person, not mess >> my the format-patch versions, changed only the cover letter, ... Quite >> afraid of bothering that big mailing list for nothing. > > Maybe using git-publish would help here: > https://github.com/stefanha/git-publish > > Using the simple git-puslish command, it manages revisions > automatically, open an editor for the cover letter, can run some scripts > to add proper maintainers, and hook available to run basic checks, > etc... Good to see that i've reinvented the wheel yet again, as this looks almost exactly like the set of scripts i wrote for myself to automate patch submission :D > > We could add a .gitpublish file to automate adding right maintainers > depending on the branch, etc... > > For example, for Qemu the .gitpublish file looks like this: > https://github.com/qemu/qemu/blob/master/.gitpublish > >> I'm infrequent enough to have te re-learn every time basically. It would >> be much easier with a git push, a fast online review of the diff, as on >> github/gitlab, and done. Also, those allow online edits, and therefore >> allows "elders" to do small fixes directly in the "patch". Some fixes >> are not worth the discussion and the chain of mails. That's what I'm >> missing the most personnaly. >> >> Tom >> > -- Thanks, Anatoly