> On May 25, 2020, at 12:32 PM, Thomas Monjalon <tho...@monjalon.net> wrote:
>
> 25/05/2020 18:57, Wiles, Keith:
>> On May 25, 2020, at 11:28 AM, Thomas Monjalon <tho...@monjalon.net> wrote:
>>> 25/05/2020 18:09, Burakov, Anatoly:
>>>> On 25-May-20 5:04 PM, Maxime Coquelin wrote:
>>>>> On 5/25/20 5:59 PM, Burakov, Anatoly wrote:
>>>>>> On 25-May-20 4:52 PM, Maxime Coquelin wrote:
>>>>>>> On 5/25/20 5:35 PM, Jerin Jacob wrote:
>>>>>>>> On May 25, 2020 Thomas Monjalon wrote:
>>>>>>>>> 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
>>>>>>>
>>>>>>> Out of curiosity, just checked the git history and I'm not that
>>>>>>> impressed. For example last commit on the master branch:
>>>>>>>
>>>>>>> https://github.com/microsoft/vscode/commit/2a4cecf3f2f72346d06990feeb7446b3915d6148
>>>>>>>
>>>>>>>
>>>>>>> Commit title: " Fix #98530 "
>>>>>>> Commit message empty, no explanation on what the patch is doing.
>>>>>>>
>>>>>>> Then, let's check the the issue it is pointed to:
>>>>>>> https://github.com/microsoft/vscode/issues/98530
>>>>>>>
>>>>>>> Issue is created 15 minutes before the patch is being merged. All that
>>>>>>> done by the same contributor, without any review.
>>>>>>>
>>>>>>
>>>>>> Just because they do it wrong doesn't mean we can't do it right :) This
>>>>>> says more about Microsoft's lack of process around VSCode than it does
>>>>>> about Github the tool.
>>>>>>
>>>>>
>>>>> True. I was just pointing out that is not the kind of process I would
>>>>> personally want to adopt.
>>>>>
>>>>
>>>> You won't find disagreement here, but this "process" is not due to the
>>>> tool. You can just as well allow Thomas to merge stuff without any
>>>> review because he has commit rights, no Github needed - and you would be
>>>> faced with the same problem.
>>>>
>>>> So, i don't think Jerin was suggesting that we degrade our merge/commit
>>>> rules. Rather, the point was that (whatever you think of VSCode's
>>>> review/merge process) there are a lot of pull requests and there is
>>>> healthy community collaboration. I'm not saying we don't have that,
>>>
>>> Yes, recent survey said the process was fine:
>>> http://mails.dpdk.org/archives/announce/2019-June/000268.html
>>
>> IMO the survey is not a great tool for these types of things. The tech board
>> and others that fully understand the process should decide. From my
>> experience using Github or Gitlab is much easy and a single tool to submit
>> patches to a project. Anatoly and others stated it very well and we should
>> convert IMO, as I have always stated in the past.
>>>
>>>
>>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>
>> Would it not free up your time and energies by have the tools
>> do most of the work. then you can focus on what matters the patch
>> and developing more features?
>
> No, GitHub is not helping to track root cause and define what should be
> backported.
> It does not help to track Coverity issues.
> It does not add Acks automatically (but patchwork does).
> It does not send a notification when enough review is done (judgement needed
> here).
> It does not split patches when different bugs are fixed.
> etc...
Thanks for reading my emails and I am trying to help DPDK as a whole.
All of these seem to be supported by GitHub or GitLab in one way or another,
but other more versed in these tools can correct me.
- We use Coverity and other tools attached to GitLab and they seem to be doing
the job. I agree we will always find issues and these tools are not a complete
answer and no tool is today.
- Acks can be done via the merge rules (at least in GitLab FWIW not used GitHub
much).
- cherry-picking a merge request into multiple commit or different merge
request appear to be supported.
- Notifications are part of the process with merge rules if I understand your
comment.
We need to drag DPDK kicking and screaming into the year 2020 :-)
>
> But yes GitHub provides a beautiful interface,
> and can help with reviews (even if not my taste).
>
> One more thing I experience sometimes, GitHub requires only one account
> for all hosted projects, so it helps leaving quick comments in projects
> we are not familiar with.
>
>
>> There is a reasons millions of developer use one of these two tools, instead
>> of emailing patch around. We are a fairly small project compared to Linux
>> Kernel and we are not developing code for the Linux kernel. Some of the
>> process like coding standard is great, but the rest is just legacy IMO and
>> not required to get the job done. Having tools to keep track of the minutia
>> should free up more of your time for the real development.
>>
>> Yes, it will be a learning curve for some and nailing down the process or
>> rules for merge requests needs to be done.
>>
>> All in all it will be a huge improvement for contributors.