[dpdk-dev] GitHub sandbox for the DPDK community

[Wiles, Keith]

Hi Marc

On 5/4/15, 2:08 PM, "Marc Sune" <marc.sune at bisdn.de> wrote:

>
>
>On 02/05/15 15:59, Wiles, Keith wrote:
>>
>> On 5/2/15, 6:40 AM, "Neil Horman" <nhorman at tuxdriver.com> wrote:
>>
>>> On Fri, May 01, 2015 at 01:36:58PM -0700, Matthew Hall wrote:
>>>> On Fri, May 01, 2015 at 10:59:32PM +0300, Aaro Koskinen wrote:
>>>>> Projects like GCC, GLIBC, binutils, busybox, etc or what?
>>>>>
>>>>> A.
>>>> You'll notice all of these are low-level UNIX hacker sorts of tools
>>>> mostly,
>>>> with the partial exception of busybox. But even that is mainly for
>>>> embedded
>>>> use. It doesn't mean I don't think they're good and useful, but it
>>>>does
>>>> limit
>>>> the possible size of the community in my view.
>>>>
>>>> Since we are talking about how to get the largest widest community
>>>> possible
>>>> for DPDK, it could require doing things a bit differently from how
>>>>many
>>>> low-level tools have historically done things.
>>>>
>>> Why?
>>>
>>> Contributors to GCC: ~600 (based on svn) review
>>> Contrubutors to glibc : ~300 (based on git) review
>>> Contributors to binutils: ~600
>>> Contributors to busybox: ~300
>>>
>>> Contributors to DPDK: ~125
>> I think the DPDK community can grow the number above and as we move
>>toward
>> VNF/NFV I think it will grow to a much wider group of developers and
>>not a
>> niche project as you stated. We can be much more then some of the above
>> IMHO.
>
>Keith,
>
>Since I didn't really know where to post this, I do it here.
>
>Like you, I think hosting the repository in github is a good idea to
>increase visibility to more developers.
>
>I am not so sure the development workflow can be shifted completely to
>github pull requests; there is a lot of controversy on this.
>
>So I would propose a middle-ground, *if* we think we can make it work:
>
>1) The mailing-list, or mailing-lists, and the github pull requests
>should be synchronized. For this we could set a small cron job or BOT
>that inspects via the github API [*] the existing pull requests and
>emails the new ones to the DPDK mailing list. All pull requests can be
>downloaded as diffs and patches:
>
>https://github.com/<org or user>/<repo_name>/pull/<number>.diff
>https://github.com/<org or user>/<repo_name>/pull/<number>.patch
>
>[*] https://developer.github.com/v3/
>
>The BOT could even do very basic checkings, such as the discussed "dpdk
>checkpatch" over the PR, and publish automatically comments on the PR
>based on conformance/no conformance of the patch style.
>
>2) Discussion in the PR could be "echoed" by the bot in the mailing
>list, respecting the subject and threading, also via github's API.
>Automatic e-mails by github doesn't seem adequate to be echoed rawly in
>the list.
>
>3) The synchronization needs to happen the other way around too. I am
>not completely sure which is the best way:
>
>a) Open an issue and reference the mailing list (DPDK mailman) for the
>patch and nothing more.
>b) More work but probably better; in a fork for the BOT of the official
>DPDK repository:
>
>    i) Make the bot get the patch from the mailing list, create a
>    branch, apply on top of current HEAD. If fails, notify the user to
>    rebase its patched, informing on top of which version could not be
>    applied
>    ii) Issue a pull request "github.com/dpdk_bot/dpdk branch <name of
>    the feature>" -> "github.com/dpdk-conmmunity/dpdk branch master"
>
>
>4) Discussions in the mailing list about a PULL request or a patch sent
>in the mailing list should be recovered by the BOT and echoed in the
>pull request
>
>5) Normal issues: since the current DPDK doesn't have an issue tracker
>(afaik) it is easy. We could simply use that one and echo a _digested_
>version of the comments into the mailing list.
>
>With this approach both "mailing list users" and "github users" should
>be able to work in parallel. Keith; what do you think? It really needs
>work, but I guess it could do the job.
>
>If you like it we could set up a small (parallel) mailing and work with
>your repository to try this "combined" workflow.

To me this seems reasonable and we can work on this with the sandbox.

Need to play with it more, but I do not have a email list someplace to
play and write the bot. Lets talk more about this outside the list and if
someone else is wanting to help please let us know and we can add you to
the discussions.

>
>Marc
>
>p.s. if by chance someone from github is listening reading, a
>functionality similar to this one would be welcome.
>
>>> Now I grant you that dpdk is a newer, much more niche project, but its
>>> disingenuous to state that we _have_ to do things differently to reach
>>>a
>>> wider
>>> audience.  We can, but its by no means a prerequisite to gainining a
>>>wider
>>> audience.
>>>
>