[dpdk-dev] GitHub sandbox for the DPDK community
Marc Sune
marc.sune at bisdn.de
Mon May 4 23:08:19 CEST 2015
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.
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.
>>
More information about the dev
mailing list