From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx.bisdn.de (mx.bisdn.de [185.27.182.31]) by dpdk.org (Postfix) with ESMTP id A284F3239 for ; Wed, 6 May 2015 23:37:38 +0200 (CEST) Received: from [192.168.1.102] (f052053078.adsl.alicedsl.de [78.52.53.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx.bisdn.de (Postfix) with ESMTPSA id 4DED4A3B27 for ; Wed, 6 May 2015 23:37:38 +0200 (CEST) Message-ID: <554A89A0.1080906@bisdn.de> Date: Wed, 06 May 2015 23:37:36 +0200 From: Marc Sune User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: dev@dpdk.org References: <3874506.o2COu6VmK6@xps13> In-Reply-To: <3874506.o2COu6VmK6@xps13> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] GitHub sandbox for the DPDK community X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 21:37:38 -0000 On 06/05/15 23:09, Thomas Monjalon wrote: > Hello everyone, > > I'm back from mini-holidays and it's good to see that there are > a lot of proposals trying to improve our workflow. > Most of the discussions are focus on process and tools, however > we must keep in mind that submitting clean patches and doing more > reviews can greatly improve the life of the project. > The debate for/against GitHub raises several interesting questions > about different parts of the workflow which deserves some detailed > explanations (and context reminders). > > Previously, there was a discussion about the contribution rules and tools: > http://dpdk.org/ml/archives/dev/2015-March/015499.html > Then a coding rules discussion was started: > http://dpdk.org/ml/archives/dev/2015-April/016243.html > And a more general thread brought some interesting opinions: > http://dpdk.org/ml/archives/dev/2015-April/016551.html > As a consequence, we are now discussing the workflow and especially > how GitHub could help us. > Please note that the follow-up of some of these discussions may be done > by submitting & reviewing patches (e.g. guidelines documents, > tools integration, etc). > Now let's talk about the workflow. > > When the dpdk.org project was started in 2013, it has been decided to adopt > an email workflow. It is the most common model in projects which are > technically close to DPDK: Linux, Qemu, GLIBC, GCC. So it is a promise to > attract contributors from these projects. Moreover, the number of comments > to this thread tends to prove that emails are not dead ;) > See also the number of contributors of previous versions: > 1.6: 25 (2014, April) > 1.7: 46 (2014, September) > 1.8: 54 (2014, December) > 2.0: 60 (2015, April) > > Another choice was done about the number of mailing lists: most of the traffic > is in only one list (dev@) in order to avoid separation between patches and > discussions/reports leading to patches. It also allows user questions to be > read by skilled developers. > > The portal to doc, git and mailing list is the website which is managed with > git in order to open it when needed and mature enough. > Please find web traffic evolution in the attached file. > There is also a patchwork web interface to ease browsing patches submitted > to the mailing list. It provides a view on patches status and agregate > discussions on specific patches. Some improvements are in progress: > http://permalink.gmane.org/gmane.comp.version-control.patchwork/1162 > https://lists.ozlabs.org/pipermail/patchwork/2015-May/001310.html > > There are 3 types of git repositories (http://dpdk.org/browse): > - the main DPDK tree > - subtrees, created on request or external, may help to scale by providing > patches ready for merge in the main tree > - side trees, created on request, e.g. dts or pktgen > Do not hesitate to request creation of a new tree, it's open. > Intel has requested some small subtrees which seems not very useful. We may > try to organize some new subtrees for bigger areas, which would take care > of many sections of the MAINTAINERS file. Maybe that some dedicated mailing > lists should be created. These mailing lists and subtrees may be hosted on > dpdk.org or elsewhere if everybody agree. > > There was no bug tracker initially installed to avoid fragmentation with > mailing-list discussions. Now that traffic is becoming huge, it appears to be > a new priority. > > Last point in the workflow status: tests and continuous integration. > It's a complicated topic, especially because DPDK requires some expensive > infrastructure for the tests. Some people are working on it at Intel and > 6WIND, so I guess we will have a public discussion in the coming weeks. > > After carefully reading previous comments about github hosting, I would like > to sort pros/cons below. > Invalidated Pro: > - web pages system: already possible without GitHub > - popularity: why being hosted on GitHub would improve the visibility? > Pros: > - less complicated command lines > - same view for everyone (independent of MUA features) > - more code context when reading patches > - integrated bug tracker > Cons: > - full feature usage implies everybody is forced to use it > - fragmentation between online data and mailing list > - discussions are not threaded, long discussions not clear > - editing in browser may be limited > - no offline access > - difficult to follow history as we rely on user repositories which may change > - GitHub (commercial service) is watching us > - how to leave and migrate data from GitHub? > - administration issues out of control (see snapshot of today's downtime) > > I did an abuse report for https://github.com/dpdk in case we want to use this > GitHub account. > My opinion is that GitHub offers some nice tools and toys but some people > won't be comfortable with it. > It may be reasonable to try some features without forcing everyone to migrate, > while keeping consistency between every contributors. > Making some tests in a sandbox seems to be a good approach. Hi Thomas, Thanks for the detailed explanation. As the official "maintainer" of DPDK, and I think strongly in favour of the current mail-based workflow, I would like to know how would you see a hybrid approach like: http://dpdk.org/ml/archives/dev/2015-May/017283.html if we would manage to make it work reliably. Best Marc > > Thanks for reading