Re: GitHub sandbox for the DPDK community

[Marc Sune <marc.sune-kpkqNMk1I7M@public.gmane.org>]

On 02/05/15 15:59, Wiles, Keith wrote:
>
> On 5/2/15, 6:40 AM, "Neil Horman" <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> 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.

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