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
> 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.
