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