Re: [dpdk-dev] GitHub sandbox for the DPDK community

[Marc Sune <marc.sune@bisdn.de>]

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