Re: [dpdk-dev] [dpdk-techboard] Consider improving the DPDKcontribution processes

["Burakov, Anatoly" <anatoly.burakov@intel.com>]

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