From: Neil Horman <nhorman@tuxdriver.com>
To: "Wiles, Keith" <keith.wiles@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] GitHub sandbox for the DPDK community
Date: Fri, 1 May 2015 12:45:12 -0400 [thread overview]
Message-ID: <20150501164512.GB27756@hmsreliant.think-freely.org> (raw)
In-Reply-To: <D1690998.1E825%keith.wiles@intel.com>
On Fri, May 01, 2015 at 03:56:32PM +0000, Wiles, Keith wrote:
> Hi Everyone,
>
> I believe the DPDK community would benefit from moving to GitHub as the
> primary DPDK site. http://github.com
>
I'm not explicitly opposed to this, but I'm having trouble matching up the
technical and governance issues raised on the list as of late with the benefits
you indicate github provides. Thoughts inline.
> I believe the DPDK community can benefit from being at a very well know
> world wide site. GitHub seems to have the most eyes of any of the open
> source Git repos today and it appears they have more then twice as many
> developers. GitHub has a number of features I see as some good additions to
> our community using the GitHub organization account type.
>
Do you think that the current site dpdk.org lacks visibility? Do we have
analytics on the site, or anecdotal evidence to suggest that more visiblity can
be had by moving to github? It seems to me that people in search of a dataplane
library google it, and dpdk is in the top 10 results, along with its wikipedia
page, etc:
https://www.google.com/#q=dataplane+library
Not sure how using github brings on additional visibility.
> The cost for an organization account is $0 as long as we do not need more
> then 5 private repos. 10 private repos is $25/month and had other plans
> for more. I do not see us needing more then 5 private repos today and the
> only reason I can see having a private repo is to do some prep work on the
> repo before making public. Every contributor would need to create a GitHub
> personal account, which is at no cost unless you need more then 5 private
> repos. In both accounts you can have unlimited public repos.
>
Given that dpdk is a public project, why would we need _any_ private
repositories? They should all be public, no?
> https://help.github.com/articles/where-can-i-find-open-source-projects-to-w
> ork-on/
>
> http://www.sitepoint.com/using-git-open-source-projects/
>
> - Adding more committers can lead to a security problems for 6Wind (I
> assume).
In what way? Are you advocating for a single comitter here, and how does Github
provide that? FWIW, I think subtree maintainers is an excellent strategy for
more efficient workflow (getting patches accepted faster has been an identified
problem), and allowing subtree maintainers with a comitter for each is a good
way to solve that. Thats implementable with github or any other git based
solution, mind you, so its neither an argument for or against github.
> - 6Wind appearing to own DPDK.org is not a good message to the community.
Why not? They're graciously hosting the site, and not advertizing on it (at
least they shouldn't be, and I don't it egregiously displayed). Netcraft will
show you lots of open source projects that host their site on a server operated
by a participating company. Care has to be taken about bias, but its not
uncommon.
> - Not assuming 6Wind¹s dpdk.org site will disappear only where the
> community stores the master repos and how the community interacts with the
> master.
That just sounds like going back to the situation we had between dpdk.org and
01.org, where there was confusion over the canonical location to go to for dpdk
information, I think we want to avoid that.
> - Permission and access levels in dpdk.org is only one level and we can
> benefit from having 4 levels and teams as well.
Not sure what you mean by this. What access levels are you envisioning, and how
is it they are not achievable with what we have today?
> - The patch process today suffers from timely reviews, which will not be
> fixed by moving.
> - GitHub has a per pull request discussions area, which gives a clean
> way to review all discussions on a specific change.
> - The current patch model is clone/modify/commit/send patch set
> - The model with GitHub is fork on GitHub/modify/commit/send pull
> request
> - The patchwork web site is reasonable, but has some draw backs in
> maintaining the site.
Can you ennumerate?
> - GitHub manages the patches via pull requests and can be easily seen
> via a web browser.
> - The down side is you do have to use a web browser to do some work, but
> the bulk of the everyday work would be done as it is today.
> - I think we all have a web browser now :-)
Yes, but as you said above, using a web browser doesn't make reviewing patches
faster. In fact, I would assert that it slows the process down, as it prevents
quick, easy command line access to patch review (as you have with a properly
configured MUA). That seems like we're going in the opposite direction of at
least one problem we would like to solve.
> - GitHub has team support and gives a group better control plus
> collaboration is much easier as we have a external location to work.
I don't understand what you mean by an external location to work. Why is that
beneficial, and why can you not just do that today if you find it beneficial.
> - Most companies have some pretty high security level and being to
> collaborate between two or more companies is very difficult if one company
> is hosting the repo behind a firewall.
If one company is hosting a git repo behind a firewall, that seems like their
problem to fix. Not sure how dpdk moving to github helps that.
> - Using GitHub and teams would make collaboration a lot easier or
> collaboration between two or more user accounts as well.
You mentioned that above already, and it still seems like an unfinished thought.
What is github providing here in terms of collaboration tools that we don't
already have? We have git, we have email, we can send pull requests, we have a
canonical location to discuss change. Whats missing?
> - GitHub has a Web Page system, which can be customized for the community
> needs via a public or private repo.
Thsi is a fair point. It might be nice to have a wiki, and github gives you
that for free. Though we could easily set one up on dpdk.org.
> - We still need a dpdk.org email list I believe as I did not find one at
> GitHub.
> - We can also forward GitHub emails to the list.
> - I believe you can reply to an email from GitHub and the email will get
And that sort of undoes the advantages of using github, as it means people need
to check multiple locations for dpdk development information. They need to use
the web site to get information about pull requests so they can review patches
(github, never sends patches via email), but you still have to check the email
list for discussions not pertaining to patches.
As noted above, I'm not explicitly opposed to using github, I use it for several
projects myself, and it does provide some nice features, but I'm not seeing how
those features address the concerns that have been brought up on the list here.
Neil
next prev parent reply other threads:[~2015-05-01 16:45 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-01 15:56 Wiles, Keith
2015-05-01 16:45 ` Neil Horman [this message]
2015-05-01 17:18 ` Aaro Koskinen
2015-05-04 12:39 ` Qiu, Michael
2015-05-01 17:31 ` Matthew Hall
2015-05-01 17:45 ` Wiles, Keith
2015-05-01 18:48 ` Neil Horman
2015-05-01 19:10 ` Wiles, Keith
2015-05-02 2:59 ` Wiles, Keith
2015-05-03 21:00 ` Neil Horman
2015-05-04 3:51 ` Wiles, Keith
2015-05-04 12:43 ` Qiu, Michael
2015-05-04 17:48 ` Matthew Hall
2015-05-04 18:52 ` Neil Horman
2015-05-05 3:12 ` Wiles, Keith
2015-05-05 3:25 ` Jim Thompson
2015-05-05 13:55 ` Neil Horman
2015-05-05 16:43 ` Wiles, Keith
2015-05-05 17:57 ` John W. Linville
2015-05-05 18:30 ` Wiles, Keith
2015-05-05 18:46 ` John W. Linville
2015-05-05 19:07 ` Neil Horman
2015-05-05 20:15 ` Wiles, Keith
2015-05-06 8:12 ` Panu Matilainen
2015-05-06 8:30 ` Simon Kågström
2015-05-06 9:00 ` Panu Matilainen
2015-05-06 10:37 ` Neil Horman
2015-05-07 15:26 ` John W. Linville
2015-05-01 18:01 ` Wiles, Keith
2015-05-01 18:09 ` Stephen Hemminger
2015-05-01 18:17 ` Wiles, Keith
2015-05-04 20:34 ` Marc Sune
2015-05-05 2:54 ` Wiles, Keith
2015-05-01 19:49 ` Matthew Hall
2015-05-01 19:59 ` Aaro Koskinen
2015-05-01 20:36 ` Matthew Hall
2015-05-02 11:40 ` Neil Horman
2015-05-02 12:37 ` Thomas F Herbert
2015-05-02 14:07 ` Wiles, Keith
2015-05-02 13:59 ` Wiles, Keith
2015-05-04 21:08 ` Marc Sune
2015-05-05 3:09 ` Wiles, Keith
2015-05-04 6:52 ` Simon
2015-05-04 9:05 ` Marc Sune
2015-05-06 10:11 ` Mcnamara, John
2015-05-06 21:09 ` Thomas Monjalon
2015-05-06 21:37 ` Marc Sune
2015-05-06 23:49 ` Wiles, Keith
2015-05-07 3:37 ` Wiles, Keith
2015-05-12 14:38 ` Thomas Monjalon
2015-05-04 5:08 Wiles, Keith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150501164512.GB27756@hmsreliant.think-freely.org \
--to=nhorman@tuxdriver.com \
--cc=dev@dpdk.org \
--cc=keith.wiles@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).