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

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

[Wiles, Keith]

On 5/1/15, 10:56 AM, "Wiles, Keith" <keith.wiles@intel.com> wrote:

>Hi Everyone,
>
>I believe the DPDK community would benefit from moving to GitHub as the
>primary DPDK site. http://github.com

Here is a good page showing the GitHub features:
https://github.com/features/


>
>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.
>
>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.
>
>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).
>- 6Wind appearing to own DPDK.org is not a good message to the community.
>  - 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.
>- Permission and access levels in dpdk.org is only one level and we can
>benefit from having 4 levels and teams as well.
>- 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.
>  - 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 :-)
>- GitHub has team support and gives a group better control plus
>collaboration is much easier as we have a external location to work.
>  - 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.
>  - Using GitHub and teams would make collaboration a lot easier or
>collaboration between two or more user accounts as well.
>- GitHub has a Web Page system, which can be customized for the community
>needs via a public or private repo.
>- 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
>appended to the discussion thread.
>
>As most do not like to read long emails :-) I will stop here and add one
>more thing.
>
>I believe moving to GitHub for the DPDK community has a lot of advantages,
>but I also understand it will be different process and will cause a bit of
>issues as we convert. Having more eyes plus in a well know public location
>plus utilizing the extra features on Github plus a better public
>modifiable web pages is a few big advantages for the DPDK community.
>
>I have create a sandbox on GitHub for anyone to play with using GitHub.
>You will need to create a GitHub account and an email me your account name
>to add you to the organization site as a contributor.
>
>The GitHub site is not a fork of dpdk.org only a sandbox to play with how
>GitHub can help the community to gain more developers in a clean manner.
>
>https://github.com/dpdk-org
>
>
>Regards
>++Keith
>
> 
>
>
>
>

[dpdk-dev] GitHub sandbox for the DPDK community

[Wiles, Keith]

Hi Everyone,

I believe the DPDK community would benefit from moving to GitHub as the
primary DPDK site. http://github.com

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.

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.

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).
- 6Wind appearing to own DPDK.org is not a good message to the community.
  - 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.
- Permission and access levels in dpdk.org is only one level and we can
benefit from having 4 levels and teams as well.
- 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.
  - 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 :-)
- GitHub has team support and gives a group better control plus
collaboration is much easier as we have a external location to work.
  - 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.
  - Using GitHub and teams would make collaboration a lot easier or
collaboration between two or more user accounts as well.
- GitHub has a Web Page system, which can be customized for the community
needs via a public or private repo.
- 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
appended to the discussion thread.

As most do not like to read long emails :-) I will stop here and add one
more thing.

I believe moving to GitHub for the DPDK community has a lot of advantages,
but I also understand it will be different process and will cause a bit of
issues as we convert. Having more eyes plus in a well know public location
plus utilizing the extra features on Github plus a better public
modifiable web pages is a few big advantages for the DPDK community.

I have create a sandbox on GitHub for anyone to play with using GitHub.
You will need to create a GitHub account and an email me your account name
to add you to the organization site as a contributor.

The GitHub site is not a fork of dpdk.org only a sandbox to play with how
GitHub can help the community to gain more developers in a clean manner.

https://github.com/dpdk-org


Regards
++Keith

 

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

[Neil Horman]

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

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

[Aaro Koskinen]

Hi,

On Fri, May 01, 2015 at 12:45:12PM -0400, Neil Horman wrote:
> >   - 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.

I agree. Having a web browser interface for reviews etc. is acceptable
only if people can still continue to use e-mail if they prefer.
I don't know how github works in this regard but patches should still
appear on the mailing list and it should be still possible to comment
them via mailing list.

A.

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

[Qiu, Michael]

On 5/2/2015 1:19 AM, Aaro Koskinen wrote:
> Hi,
>
> On Fri, May 01, 2015 at 12:45:12PM -0400, Neil Horman wrote:
>>>   - 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.
> I agree. Having a web browser interface for reviews etc. is acceptable
> only if people can still continue to use e-mail if they prefer.
> I don't know how github works in this regard but patches should still
> appear on the mailing list and it should be still possible to comment
> them via mailing list.

How it comes?

As I know if use github, the maillist will be meaningless.

And do you know some area on the earth maybe have issue with github?

Anyway, Github is OK to me, but I prefer maillist :).

Thanks,
Michael 

> A.
>

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

[Matthew Hall]

On Fri, May 01, 2015 at 12:45:12PM -0400, Neil Horman wrote:
> 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.

Normally I'm a big command-line supporter. However I have found reviewing 
patches by email for me is about the most painful workflow.

The emails are pages and pages.

The replies from commenters are buried in the walls of text.

Replies to replies keep shifting farther off the edge of the screen. The code 
gets weirder and weirder to try to read.

Quickly reading over the patchset by scrolling through to get the flavor of 
it, to see if I'm qualified to review it, and look at the parts I actually 
know about is much harder.

I can go to one place to see every candidate patchset out there, the GH Pull 
Request page. Then I can just sync up the branch and test it on my own systems 
to see if it works, not just try to read it.

Github automatically minimizes old comments that are already fixed, so they 
don't keep consuming space and mental bandwidth from the review.

All in all, I'd be able to review more DPDK patches faster with the GH 
interface than having them in the mailing list.

Matthew.

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

[Wiles, Keith]

On 5/1/15, 12:31 PM, "Matthew Hall" <mhall@mhcomputing.net> wrote:

>Normally I'm a big command-line supporter. However I have found reviewing
>patches by email for me is about the most painful workflow.
>
>The emails are pages and pages.
>
>The replies from commenters are buried in the walls of text.
>
>Replies to replies keep shifting farther off the edge of the screen. The
>code 
>gets weirder and weirder to try to read.
>
>Quickly reading over the patchset by scrolling through to get the flavor
>of 
>it, to see if I'm qualified to review it, and look at the parts I
>actually 
>know about is much harder.
>
>I can go to one place to see every candidate patchset out there, the GH
>Pull 
>Request page. Then I can just sync up the branch and test it on my own
>systems 
>to see if it works, not just try to read it.
>
>Github automatically minimizes old comments that are already fixed, so
>they 
>don't keep consuming space and mental bandwidth from the review.
>
>All in all, I'd be able to review more DPDK patches faster with the GH
>interface than having them in the mailing list.

+1 and very well stated.
>
>Matthew.
>

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

[Neil Horman]

On Fri, May 01, 2015 at 10:31:08AM -0700, Matthew Hall wrote:
> On Fri, May 01, 2015 at 12:45:12PM -0400, Neil Horman wrote:
> > 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.
> 
> Normally I'm a big command-line supporter. However I have found reviewing 
> patches by email for me is about the most painful workflow.
> 
> The emails are pages and pages.
> 
So collapse the quoted text (see below)

> The replies from commenters are buried in the walls of text.
> 
Again, collapse the text, many MUA's let you do that, its not a feature unique
to github.

> Replies to replies keep shifting farther off the edge of the screen. The code 
> gets weirder and weirder to try to read.
> 
Text Collapse will reformat that for you.

> Quickly reading over the patchset by scrolling through to get the flavor of 
> it, to see if I'm qualified to review it, and look at the parts I actually 
> know about is much harder.
> 
Thats what the origional post is for, no?  Look at that to determine if you are
qualified to read it.

> I can go to one place to see every candidate patchset out there, the GH Pull 
> Request page. Then I can just sync up the branch and test it on my own systems 
> to see if it works, not just try to read it.
> 
how is that different from a mailing list?  both let you search for posts, and
both allow you to sync git branches (github via git remote/pull, mailing list
via git am)

> Github automatically minimizes old comments that are already fixed, so they 
> don't keep consuming space and mental bandwidth from the review.
An MUA can do that too.  IIRC evolution and thunderbird both have collapse
features.  I'm sure others do too.

> 
> All in all, I'd be able to review more DPDK patches faster with the GH 
> interface than having them in the mailing list.
> 
> Matthew.
> 

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

[Wiles, Keith]

On 5/1/15, 1:48 PM, "Neil Horman" <nhorman@tuxdriver.com> wrote:

>On Fri, May 01, 2015 at 10:31:08AM -0700, Matthew Hall wrote:
>> On Fri, May 01, 2015 at 12:45:12PM -0400, Neil Horman wrote:
>> > 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.
>> 
>> Normally I'm a big command-line supporter. However I have found
>>reviewing 
>> patches by email for me is about the most painful workflow.
>> 
>> The emails are pages and pages.
>> 
>So collapse the quoted text (see below)
>
>> The replies from commenters are buried in the walls of text.
>> 
>Again, collapse the text, many MUA's let you do that, its not a feature
>unique
>to github.
>
>> Replies to replies keep shifting farther off the edge of the screen.
>>The code 
>> gets weirder and weirder to try to read.
>> 
>Text Collapse will reformat that for you.
>
>> Quickly reading over the patchset by scrolling through to get the
>>flavor of 
>> it, to see if I'm qualified to review it, and look at the parts I
>>actually 
>> know about is much harder.
>> 
>Thats what the origional post is for, no?  Look at that to determine if
>you are
>qualified to read it.
>
>> I can go to one place to see every candidate patchset out there, the GH
>>Pull 
>> Request page. Then I can just sync up the branch and test it on my own
>>systems 
>> to see if it works, not just try to read it.
>> 
>how is that different from a mailing list?  both let you search for
>posts, and
>both allow you to sync git branches (github via git remote/pull, mailing
>list
>via git am)
>
>> Github automatically minimizes old comments that are already fixed, so
>>they 
>> don't keep consuming space and mental bandwidth from the review.
>An MUA can do that too.  IIRC evolution and thunderbird both have collapse
>features.  I'm sure others do too.

Not all email clients allow for collapsing threads, I am using outlook for
Mac and I do not think the windows version has that feature. I am not sure
Apple mail client can handle collapsing or not as I am stuck with outlook
as my email virus (I mean client) :-)

The point here is all emails clients have different ways of displaying the
information some good some bad. I see the GitHub method to be different,
but for me I am able to understand the way it handles comments and patches.

I have the same problems as Matthew, but I do not want to get into a email
client wars.

>
>> 
>> All in all, I'd be able to review more DPDK patches faster with the GH
>> interface than having them in the mailing list.
>> 
>> Matthew.
>> 

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

[Wiles, Keith]

On 5/1/15, 2:10 PM, "Wiles, Keith" <keith.wiles@intel.com> wrote:

>
>
>On 5/1/15, 1:48 PM, "Neil Horman" <nhorman@tuxdriver.com> wrote:
>
>>On Fri, May 01, 2015 at 10:31:08AM -0700, Matthew Hall wrote:
>>> On Fri, May 01, 2015 at 12:45:12PM -0400, Neil Horman wrote:
>>> > 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.
>>> 
>>> Normally I'm a big command-line supporter. However I have found
>>>reviewing 
>>> patches by email for me is about the most painful workflow.
>>> 
>>> The emails are pages and pages.
>>> 
>>So collapse the quoted text (see below)
>>
>>> The replies from commenters are buried in the walls of text.
>>> 
>>Again, collapse the text, many MUA's let you do that, its not a feature
>>unique
>>to github.
>>
>>> Replies to replies keep shifting farther off the edge of the screen.
>>>The code 
>>> gets weirder and weirder to try to read.
>>> 
>>Text Collapse will reformat that for you.
>>
>>> Quickly reading over the patchset by scrolling through to get the
>>>flavor of 
>>> it, to see if I'm qualified to review it, and look at the parts I
>>>actually 
>>> know about is much harder.
>>> 
>>Thats what the origional post is for, no?  Look at that to determine if
>>you are
>>qualified to read it.
>>
>>> I can go to one place to see every candidate patchset out there, the GH
>>>Pull 
>>> Request page. Then I can just sync up the branch and test it on my own
>>>systems 
>>> to see if it works, not just try to read it.
>>> 
>>how is that different from a mailing list?  both let you search for
>>posts, and
>>both allow you to sync git branches (github via git remote/pull, mailing
>>list
>>via git am)
>>
>>> Github automatically minimizes old comments that are already fixed, so
>>>they 
>>> don't keep consuming space and mental bandwidth from the review.
>>An MUA can do that too.  IIRC evolution and thunderbird both have
>>collapse
>>features.  I'm sure others do too.
>
>Not all email clients allow for collapsing threads, I am using outlook for
>Mac and I do not think the windows version has that feature. I am not sure
>Apple mail client can handle collapsing or not as I am stuck with outlook
>as my email virus (I mean client) :-)
>
>The point here is all emails clients have different ways of displaying the
>information some good some bad. I see the GitHub method to be different,
>but for me I am able to understand the way it handles comments and
>patches.
>
>I have the same problems as Matthew, but I do not want to get into a email
>client wars.
>
>>
>>> 
>>> All in all, I'd be able to review more DPDK patches faster with the GH
>>> interface than having them in the mailing list.
>>> 
>>> Matthew.
>>> 

Added a wiki site via GitHub located at : http://dpdk-org.github.io/dpdk
>

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

[Neil Horman]

On Fri, May 01, 2015 at 07:10:11PM +0000, Wiles, Keith wrote:
> 
> 
> On 5/1/15, 1:48 PM, "Neil Horman" <nhorman@tuxdriver.com> wrote:
> 
> >On Fri, May 01, 2015 at 10:31:08AM -0700, Matthew Hall wrote:
> >> On Fri, May 01, 2015 at 12:45:12PM -0400, Neil Horman wrote:
> >> > 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.
> >> 
> >> Normally I'm a big command-line supporter. However I have found
> >>reviewing 
> >> patches by email for me is about the most painful workflow.
> >> 
> >> The emails are pages and pages.
> >> 
> >So collapse the quoted text (see below)
> >
> >> The replies from commenters are buried in the walls of text.
> >> 
> >Again, collapse the text, many MUA's let you do that, its not a feature
> >unique
> >to github.
> >
> >> Replies to replies keep shifting farther off the edge of the screen.
> >>The code 
> >> gets weirder and weirder to try to read.
> >> 
> >Text Collapse will reformat that for you.
> >
> >> Quickly reading over the patchset by scrolling through to get the
> >>flavor of 
> >> it, to see if I'm qualified to review it, and look at the parts I
> >>actually 
> >> know about is much harder.
> >> 
> >Thats what the origional post is for, no?  Look at that to determine if
> >you are
> >qualified to read it.
> >
> >> I can go to one place to see every candidate patchset out there, the GH
> >>Pull 
> >> Request page. Then I can just sync up the branch and test it on my own
> >>systems 
> >> to see if it works, not just try to read it.
> >> 
> >how is that different from a mailing list?  both let you search for
> >posts, and
> >both allow you to sync git branches (github via git remote/pull, mailing
> >list
> >via git am)
> >
> >> Github automatically minimizes old comments that are already fixed, so
> >>they 
> >> don't keep consuming space and mental bandwidth from the review.
> >An MUA can do that too.  IIRC evolution and thunderbird both have collapse
> >features.  I'm sure others do too.
> 
> Not all email clients allow for collapsing threads, I am using outlook for
> Mac and I do not think the windows version has that feature. I am not sure
> Apple mail client can handle collapsing or not as I am stuck with outlook
> as my email virus (I mean client) :-)
> 
Ok, but this isn't about ensuring we can do everything with all email clients.
You asserted that you wanted a feature whereby conversations can be collapsed
for easier parsing of the most recent post.  I'm fine without that, but if you
want it, thats fine too.  My point was that you can have that feature without
needing to move our development environment.  If your current client doesn't
support doing that, you're free to choose another MUA, since its clear that many
MUA's do support what you want.  

Before you assert that your employer is
going to mandate that you use a specific MUA, and that you can't possibly
change, I'll indicate that theres nothing wrong with using a different email
address/service to do your upstream work.  I use my tuxdriver address rather
than my redhat address simply because (among other reasons), I don't want to
have to log into my corporate vpn every time I send upstream email.

If you then plan on asserting that your employer mandate that you use your
corporate email address to do upstream work, I'll indicate that you have a
problem with your employer.  They require that you do work using a process and
tool suite that is non-condusive/incompatible with your preferred workflow.

My overall point is, while this is a fine feature I suppose, I don't need it,
and while I don't want to prevent others from using it, I don't consider it a
reason to undertake the effort of moving hosting to a different location,
because the feature can be had without doing so.

> The point here is all emails clients have different ways of displaying the
> information some good some bad. I see the GitHub method to be different,
> but for me I am able to understand the way it handles comments and patches.
> 
Thats great, but why should we adopt a workflow because you want a feature that
can be had without doing so?  Clearly there are other arguments here, but this
is the one we're discussing in this thread, and it seems like its not a reason
to move to me.

> I have the same problems as Matthew, but I do not want to get into a email
> client wars.
> 
Then don't, just quietly pick an MUA that implements the features that you want.
I'm not trying to mandate any particular client, just pointing out that the one
that you are using doesn't give you the features that you want.  You can choose
differently.
Neil

> >
> >> 
> >> All in all, I'd be able to review more DPDK patches faster with the GH
> >> interface than having them in the mailing list.
> >> 
And I'm exactly the opposite.  So what are we to do?
Neil

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

[Wiles, Keith]

Neil

On 5/3/15, 2:00 PM, "Neil Horman" <nhorman@tuxdriver.com> wrote:

>On Fri, May 01, 2015 at 07:10:11PM +0000, Wiles, Keith wrote:
>> 
>> 
>> On 5/1/15, 1:48 PM, "Neil Horman" <nhorman@tuxdriver.com> wrote:
>> 
>> >On Fri, May 01, 2015 at 10:31:08AM -0700, Matthew Hall wrote:
>> >> On Fri, May 01, 2015 at 12:45:12PM -0400, Neil Horman wrote:
>> >> > 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.
>> >> 
>> >> Normally I'm a big command-line supporter. However I have found
>> >>reviewing 
>> >> patches by email for me is about the most painful workflow.
>> >> 
>> >> The emails are pages and pages.
>> >> 
>> >So collapse the quoted text (see below)
>> >
>> >> The replies from commenters are buried in the walls of text.
>> >> 
>> >Again, collapse the text, many MUA's let you do that, its not a feature
>> >unique
>> >to github.
>> >
>> >> Replies to replies keep shifting farther off the edge of the screen.
>> >>The code 
>> >> gets weirder and weirder to try to read.
>> >> 
>> >Text Collapse will reformat that for you.
>> >
>> >> Quickly reading over the patchset by scrolling through to get the
>> >>flavor of 
>> >> it, to see if I'm qualified to review it, and look at the parts I
>> >>actually 
>> >> know about is much harder.
>> >> 
>> >Thats what the origional post is for, no?  Look at that to determine if
>> >you are
>> >qualified to read it.
>> >
>> >> I can go to one place to see every candidate patchset out there, the
>>GH
>> >>Pull 
>> >> Request page. Then I can just sync up the branch and test it on my
>>own
>> >>systems 
>> >> to see if it works, not just try to read it.
>> >> 
>> >how is that different from a mailing list?  both let you search for
>> >posts, and
>> >both allow you to sync git branches (github via git remote/pull,
>>mailing
>> >list
>> >via git am)
>> >
>> >> Github automatically minimizes old comments that are already fixed,
>>so
>> >>they 
>> >> don't keep consuming space and mental bandwidth from the review.
>> >An MUA can do that too.  IIRC evolution and thunderbird both have
>>collapse
>> >features.  I'm sure others do too.
>> 
>> Not all email clients allow for collapsing threads, I am using outlook
>>for
>> Mac and I do not think the windows version has that feature. I am not
>>sure
>> Apple mail client can handle collapsing or not as I am stuck with
>>outlook
>> as my email virus (I mean client) :-)
>> 
>Ok, but this isn't about ensuring we can do everything with all email
>clients.
>You asserted that you wanted a feature whereby conversations can be
>collapsed

I never stated I needed conversation collapse support. I pointing out that
not everyone has that feature and besides that is not the point, in the gh
style the comments are different and some like that style just like you
prefer your style. 

Not everyone is comfortable with the style we have today. The community
needs to grow and will IMO because we will be getting people from VNF/NFV
world.

I am sorry some will need to change a bit, but the change will be for the
community and those to come.

>for easier parsing of the most recent post.  I'm fine without that, but
>if you
>want it, thats fine too.  My point was that you can have that feature
>without
>needing to move our development environment.  If your current client
>doesn't
>support doing that, you're free to choose another MUA, since its clear
>that many
>MUA's do support what you want.
>
>Before you assert that your employer is
>going to mandate that you use a specific MUA, and that you can't possibly
>change, I'll indicate that theres nothing wrong with using a different
>email
>address/service to do your upstream work.  I use my tuxdriver address
>rather
>than my redhat address simply because (among other reasons), I don't want
>to
>have to log into my corporate vpn every time I send upstream email.
>
>If you then plan on asserting that your employer mandate that you use your
>corporate email address to do upstream work, I'll indicate that you have a
>problem with your employer.  They require that you do work using a
>process and
>tool suite that is non-condusive/incompatible with your preferred
>workflow.
>
>My overall point is, while this is a fine feature I suppose, I don't need
>it,
>and while I don't want to prevent others from using it, I don't consider
>it a
>reason to undertake the effort of moving hosting to a different location,
>because the feature can be had without doing so.
>
>> The point here is all emails clients have different ways of displaying
>>the
>> information some good some bad. I see the GitHub method to be different,
>> but for me I am able to understand the way it handles comments and
>>patches.
>> 
>Thats great, but why should we adopt a workflow because you want a
>feature that
>can be had without doing so?  Clearly there are other arguments here, but
>this
>is the one we're discussing in this thread, and it seems like its not a
>reason
>to move to me.
>
>> I have the same problems as Matthew, but I do not want to get into a
>>email
>> client wars.
>> 
>Then don't, just quietly pick an MUA that implements the features that
>you want.
>I'm not trying to mandate any particular client, just pointing out that
>the one
>that you are using doesn't give you the features that you want.  You can
>choose
>differently.
>Neil

Not going to be dragged into a discussion about why I use the email client
I use. It is completely non-productive for this discussion. Keeping the
current system or moving to a new system because of a email client feature
is not really the point I was trying to make. Also I think Matthew was
pointing out their are different ways to read the comments and emails do
not appear to be good for him or me to be the most efficient with the
growing number of emails.

GH has a huge following (9.4 million users and 22.3m repos) and they must
be doing something right. An we all want the DPDK community to grow right?
We some of the brightest and best people here in the DPDK community we
should be able to figure out how to make it work for the future.

https://github.com/about/press



>
>> >
>> >> 
>> >> All in all, I'd be able to review more DPDK patches faster with the
>>GH
>> >> interface than having them in the mailing list.
>> >> 
>And I'm exactly the opposite.  So what are we to do?
>Neil


I want everyone to give his/her comments on the subject. I want the
comments to stop saying why something can not be done and start looking at
the future of the DPDK community.

I believe GH is the best direction as the current DPDK patch processes,
command line and email lists is not helping us expand and grow the DPDK
community. Moving to GH will give us a lot more eyes and a place that
seems very easy to use. GH has spent a great deal of time and money to
make GH the best place for open source projects and the numbers to not lie.

Maybe some of the current open source projects you have pointed out
started before GH was popular and maybe they have become stable or into
their mid-life. DPDK is not at its mid-life yet and NFV users IMO will be
the new group of people to work with DPDK.

I can see us defining and building a large number of open source platforms
using DPDK. I do not want to keep DPDK static and not moving forward, but
increase its appeal to others and GH seems like a good place to start.
Other directions would cost money and/or time to setup and GH is right
there let take advantage of it.

Moving to GH gives us a great chance to change a number of things for the
better. Splitting up the repo into drivers and main line code as you have
suggested. Please tell how to make GH work as I believe it is the way of
the future of DPDK community. You and others can help tell us how to make
GH work for everyone old and new.

Neil, I know I stated a bunch of stuff you really want to jump all over
and reply to, but please lets try to hear from others before we get to far
off track.

Regards,
++Keith



>

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

[Qiu, Michael]

On 5/2/2015 1:33 AM, Matthew Hall wrote:
> On Fri, May 01, 2015 at 12:45:12PM -0400, Neil Horman wrote:
>> 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.
> Normally I'm a big command-line supporter. However I have found reviewing 
> patches by email for me is about the most painful workflow.

What mail client do you use? I think  mail client supporting thread mode
is important for patch review.

Thanks,
Michael
>
> The emails are pages and pages.
>
> The replies from commenters are buried in the walls of text.
>
> Replies to replies keep shifting farther off the edge of the screen. The code 
> gets weirder and weirder to try to read.
>
> Quickly reading over the patchset by scrolling through to get the flavor of 
> it, to see if I'm qualified to review it, and look at the parts I actually 
> know about is much harder.
>
> I can go to one place to see every candidate patchset out there, the GH Pull 
> Request page. Then I can just sync up the branch and test it on my own systems 
> to see if it works, not just try to read it.
>
> Github automatically minimizes old comments that are already fixed, so they 
> don't keep consuming space and mental bandwidth from the review.
>
> All in all, I'd be able to review more DPDK patches faster with the GH 
> interface than having them in the mailing list.
>
> Matthew.
>

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

[Matthew Hall]

On Mon, May 04, 2015 at 12:43:48PM +0000, Qiu, Michael wrote:
> What mail client do you use? I think  mail client supporting thread mode
> is important for patch review.

Like many UNIX people, I use mutt.

My concern is that, if we're making the widespread adoption, usage, and 
contributions for DPDK dependent on selection or debate of the features of 
various MUAs, I'm not sure that we're looking at this from the right angle.

I'm just trying to figure out how to get DPDK in the place where the most 
eyeballs are, rather than trying to drag the eyeballs to the place where DPDK 
is.

Matthew.

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

[Neil Horman]

On Mon, May 04, 2015 at 10:48:57AM -0700, Matthew Hall wrote:
> On Mon, May 04, 2015 at 12:43:48PM +0000, Qiu, Michael wrote:
> > What mail client do you use? I think  mail client supporting thread mode
> > is important for patch review.
> 
> Like many UNIX people, I use mutt.
> 
> My concern is that, if we're making the widespread adoption, usage, and 
> contributions for DPDK dependent on selection or debate of the features of 
> various MUAs, I'm not sure that we're looking at this from the right angle.
> 

I think the exact opposite is being asserted here.  To use the example being
discussed, if you feel that quote collapsing is an important feature to your
workflow, then pick an MUA that gives you that feature.  Theres no need to
mandate a workflow that is implemented by a service like github, just so that
some set of features is available to those that like it.

Neil

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

[Wiles, Keith]

On 5/4/15, 10:48 AM, "Matthew Hall" <mhall@mhcomputing.net> wrote:

>On Mon, May 04, 2015 at 12:43:48PM +0000, Qiu, Michael wrote:
>> What mail client do you use? I think  mail client supporting thread mode
>> is important for patch review.
>
>Like many UNIX people, I use mutt.
>
>My concern is that, if we're making the widespread adoption, usage, and
>contributions for DPDK dependent on selection or debate of the features
>of 
>various MUAs, I'm not sure that we're looking at this from the right
>angle.
>
>I'm just trying to figure out how to get DPDK in the place where the most
>eyeballs are, rather than trying to drag the eyeballs to the place where
>DPDK 
>is.

+1, I agree with this statement completely and I feel discussions about an
MUA is non-productive and out of scope.
>
>Matthew.

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

[Jim Thompson]

> On May 4, 2015, at 10:12 PM, Wiles, Keith <keith.wiles@intel.com> wrote:
> 
> 
> 
> On 5/4/15, 10:48 AM, "Matthew Hall" <mhall@mhcomputing.net> wrote:
> 
>> On Mon, May 04, 2015 at 12:43:48PM +0000, Qiu, Michael wrote:
>>> What mail client do you use? I think  mail client supporting thread mode
>>> is important for patch review.
>> 
>> Like many UNIX people, I use mutt.
>> 
>> My concern is that, if we're making the widespread adoption, usage, and
>> contributions for DPDK dependent on selection or debate of the features
>> of 
>> various MUAs, I'm not sure that we're looking at this from the right
>> angle.
>> 
>> I'm just trying to figure out how to get DPDK in the place where the most
>> eyeballs are, rather than trying to drag the eyeballs to the place where
>> DPDK 
>> is.
> 
> +1, I agree with this statement completely and I feel discussions about an
> MUA is non-productive and out of scope.

+1.  I’ve avoided the whole discussion, because … ok, “non-productive and out of scope” is a polite way of saying it.

jim

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

[Neil Horman]

On Mon, May 04, 2015 at 10:25:00PM -0500, Jim Thompson wrote:
> 
> > On May 4, 2015, at 10:12 PM, Wiles, Keith <keith.wiles@intel.com> wrote:
> > 
> > 
> > 
> > On 5/4/15, 10:48 AM, "Matthew Hall" <mhall@mhcomputing.net> wrote:
> > 
> >> On Mon, May 04, 2015 at 12:43:48PM +0000, Qiu, Michael wrote:
> >>> What mail client do you use? I think  mail client supporting thread mode
> >>> is important for patch review.
> >> 
> >> Like many UNIX people, I use mutt.
> >> 
> >> My concern is that, if we're making the widespread adoption, usage, and
> >> contributions for DPDK dependent on selection or debate of the features
> >> of 
> >> various MUAs, I'm not sure that we're looking at this from the right
> >> angle.
> >> 
> >> I'm just trying to figure out how to get DPDK in the place where the most
> >> eyeballs are, rather than trying to drag the eyeballs to the place where
> >> DPDK 
> >> is.
> > 
> > +1, I agree with this statement completely and I feel discussions about an
> > MUA is non-productive and out of scope.
> 
> +1.  I’ve avoided the whole discussion, because … ok, “non-productive and out of scope” is a polite way of saying it.
> 
> jim
> 
> 

Very well, since you seem to want to avoid talking about ways to get what you
want in a workflow, lets go back to where the conversation started:

http://dpdk.org/ml/archives/dev/2015-May/017225.html

We got into this debate because you wanted to move the project to github, and as
supporting reasons, listed a plethora of features that you liked about the site.
This entire subtread has been meant to illustrate how you can have the features
you want that you see as adventageous in the github environment without actualy
moving to github.  We've focused on email quote collapsing because we kept
responding to one another, though I'm sure we could have the same debate on any
one of the workflow features github offers.

Can we all agree then, that for the list posted in your email above, any github
environmental feature can be recreated with proper tooling, available today,
without forcing the github environment on everybody?  Further, can we agree
that, given that those features are not unique to github, they are not
compelling reasons to move the project there?

Neil

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

[Wiles, Keith]

Sent from my iPhone

> On May 5, 2015, at 6:56 AM, Neil Horman <nhorman@tuxdriver.com> wrote:
> 
>> On Mon, May 04, 2015 at 10:25:00PM -0500, Jim Thompson wrote:
>> 
>>> On May 4, 2015, at 10:12 PM, Wiles, Keith <keith.wiles@intel.com> wrote:
>>> 
>>> 
>>> 
>>>> On 5/4/15, 10:48 AM, "Matthew Hall" <mhall@mhcomputing.net> wrote:
>>>> 
>>>>> On Mon, May 04, 2015 at 12:43:48PM +0000, Qiu, Michael wrote:
>>>>> What mail client do you use? I think  mail client supporting thread mode
>>>>> is important for patch review.
>>>> 
>>>> Like many UNIX people, I use mutt.
>>>> 
>>>> My concern is that, if we're making the widespread adoption, usage, and
>>>> contributions for DPDK dependent on selection or debate of the features
>>>> of 
>>>> various MUAs, I'm not sure that we're looking at this from the right
>>>> angle.
>>>> 
>>>> I'm just trying to figure out how to get DPDK in the place where the most
>>>> eyeballs are, rather than trying to drag the eyeballs to the place where
>>>> DPDK 
>>>> is.
>>> 
>>> +1, I agree with this statement completely and I feel discussions about an
>>> MUA is non-productive and out of scope.
>> 
>> +1.  I’ve avoided the whole discussion, because … ok, “non-productive and out of scope” is a polite way of saying it.
>> 
>> jim
> 
> Very well, since you seem to want to avoid talking about ways to get what you
> want in a workflow, lets go back to where the conversation started:
> 
> http://dpdk.org/ml/archives/dev/2015-May/017225.html
> 
> We got into this debate because you wanted to move the project to github, and as
> supporting reasons, listed a plethora of features that you liked about the site.
> This entire subtread has been meant to illustrate how you can have the features
> you want that you see as adventageous in the github environment without actualy
> moving to github.  We've focused on email quote collapsing because we kept
> responding to one another, though I'm sure we could have the same debate on any
> one of the workflow features github offers.
> 
> Can we all agree then, that for the list posted in your email above, any github
> environmental feature can be recreated with proper tooling, available today,
> without forcing the github environment on everybody?  Further, can we agree
> that, given that those features are not unique to github, they are not
> compelling reasons to move the project there?

Neil (I had to type this on my phone so please forgive any typos or other statements that may sound odd. I am not trying to be rude in anyway)

I feel you are taking everything out of context here. The email client being able collapse threads is not the point here and I have tried to redirect you politely to the points moving DPDK to github. 

As I and others have pointed out GitHub offers a huge number eyes for DPDK community. GitHub offers a different set of processes and tools, which we do not have to create. Moving to GitHub is a change for the community and I feel a good change for the better. 

For your statements above I say NO we do not agree as much as your arguments around a single feature of an email client is not a compelling reason to accept your statements. 

Github gives us the DPDK community a better and more widely accepted place to allow DPDK to grow and become the open source project we all want IMO. 

I want to be polite here and we are not going to agree with keeping DPDK as it is today. We need to grow and change is the only way, I believe moving to GitHub gives the best support and eyeballs on DPDK to grow. 

The tools supported on GitHub are different and yes you may need to change. The day to day development will remain the same and as we know that is the bulk of the work. The pushing of patches will change, which should be easier for move people to understand plus use. 

We could spend a lot of time and money to update the current system, but why when we could start the move to GitHub today and use those tools for free. 

I do not want this to become a flame war or something like it. I want us to try and figure out how we can improve the DPDK community. I can see keeping DPDK the way it is today, but this will stagnate DPDK IMHO and no one wants this to happen. 

I do not want to split the DPDK community or try alienating any one. 

Please take a breath and relax as we all want the best for DPDK. 

Regards,
++Keith

> 
> Neil
> 

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

[John W. Linville]

On Tue, May 05, 2015 at 04:43:08PM +0000, Wiles, Keith wrote:

> Please take a breath and relax as we all want the best for DPDK. 

I cannot believe how rude, asinine, and condascending your attitude
in this thread has been.  If this is the future of the DPDK community,
I'm surprised that anyone would want to be part of it.  Neil disagreed
with some of your assertions, and now you are trying to make him
seem like some sort of foolish twit that can't see beyond his own
preferred environment-- pot, kettle, black.

As for the 'millions of eyeballs' at GitHub...just how many of those
Go, Ruby, Python, and Swift developers are going to be contributing to
DPDK and all those future NFV projects?  And how many significant,
existing DPDK contributors (like Neil) are you isolating in the
process?  Do you even care?

Old-school IBM had the right motto -- THINK.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

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

[Wiles, Keith]

Sent from my iPhone

> On May 5, 2015, at 10:58 AM, John W. Linville <linville@tuxdriver.com> wrote:
> 
>> On Tue, May 05, 2015 at 04:43:08PM +0000, Wiles, Keith wrote:
>> 
>> Please take a breath and relax as we all want the best for DPDK

Hi John

I am sorry you see it this way as I stated in the email parts you snipped off, I was not trying do exactly what you accuse me of doing!

Thank you for comments which are non-productive in the bigger scope of this topic. 

Not to sound condescending again, can you keep the rude comments and attitude out of the discussion. 

Thank you
Keith

> I cannot believe how rude, asinine, and condascending your attitude
> in this thread has been.  If this is the future of the DPDK community,
> I'm surprised that anyone would want to be part of it.  Neil disagreed
> with some of your assertions, and now you are trying to make him
> seem like some sort of foolish twit that can't see beyond his own
> preferred environment-- pot, kettle, black.
> 
> As for the 'millions of eyeballs' at GitHub...just how many of those
> Go, Ruby, Python, and Swift developers are going to be contributing to
> DPDK and all those future NFV projects?  And how many significant,
> existing DPDK contributors (like Neil) are you isolating in the
> process?  Do you even care?
> 
> Old-school IBM had the right motto -- THINK.
> 
> John
> -- 
> John W. Linville        Someday the world will need a hero, and you
> linville@tuxdriver.com            might be all we have.  Be ready.

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

[John W. Linville]

On Tue, May 05, 2015 at 06:30:48PM +0000, Wiles, Keith wrote:
> 
> Sent from my iPhone
> 
> > On May 5, 2015, at 10:58 AM, John W. Linville <linville@tuxdriver.com> wrote:
> > 
> >> On Tue, May 05, 2015 at 04:43:08PM +0000, Wiles, Keith wrote:
> >> 
> >> Please take a breath and relax as we all want the best for DPDK
> 
> Hi John
> 
> I am sorry you see it this way as I stated in the email parts you snipped off, I was not trying do exactly what you accuse me of doing!
> 
> Thank you for comments which are non-productive in the bigger scope of this topic. 
> 
> Not to sound condescending again, can you keep the rude comments and attitude out of the discussion. 

Wow...really?  Someone calls you on your crap and all you have is the
"I know you are but what am I" defense?  Sad.

Perhaps you should take the advice that you so kindly offered to Neil...

John

P.S.  If it's alright with you, I'm trimming the rest of my message
that you quoted for no obvious reason.  In the old days, we called
that "Netiquette".  It's what we used to solve most of the problems
that you've been claiming can only be solved by GitHub.
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

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

[Neil Horman]

On Tue, May 05, 2015 at 04:43:08PM +0000, Wiles, Keith wrote:
> 
> 
> Sent from my iPhone
> 
> > On May 5, 2015, at 6:56 AM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > 
> >> On Mon, May 04, 2015 at 10:25:00PM -0500, Jim Thompson wrote:
> >> 
> >>> On May 4, 2015, at 10:12 PM, Wiles, Keith <keith.wiles@intel.com> wrote:
> >>> 
> >>> 
> >>> 
> >>>> On 5/4/15, 10:48 AM, "Matthew Hall" <mhall@mhcomputing.net> wrote:
> >>>> 
> >>>>> On Mon, May 04, 2015 at 12:43:48PM +0000, Qiu, Michael wrote:
> >>>>> What mail client do you use? I think  mail client supporting thread mode
> >>>>> is important for patch review.
> >>>> 
> >>>> Like many UNIX people, I use mutt.
> >>>> 
> >>>> My concern is that, if we're making the widespread adoption, usage, and
> >>>> contributions for DPDK dependent on selection or debate of the features
> >>>> of 
> >>>> various MUAs, I'm not sure that we're looking at this from the right
> >>>> angle.
> >>>> 
> >>>> I'm just trying to figure out how to get DPDK in the place where the most
> >>>> eyeballs are, rather than trying to drag the eyeballs to the place where
> >>>> DPDK 
> >>>> is.
> >>> 
> >>> +1, I agree with this statement completely and I feel discussions about an
> >>> MUA is non-productive and out of scope.
> >> 
> >> +1.  I’ve avoided the whole discussion, because … ok, “non-productive and out of scope” is a polite way of saying it.
> >> 
> >> jim
> > 
> > Very well, since you seem to want to avoid talking about ways to get what you
> > want in a workflow, lets go back to where the conversation started:
> > 
> > http://dpdk.org/ml/archives/dev/2015-May/017225.html
> > 
> > We got into this debate because you wanted to move the project to github, and as
> > supporting reasons, listed a plethora of features that you liked about the site.
> > This entire subtread has been meant to illustrate how you can have the features
> > you want that you see as adventageous in the github environment without actualy
> > moving to github.  We've focused on email quote collapsing because we kept
> > responding to one another, though I'm sure we could have the same debate on any
> > one of the workflow features github offers.
> > 
> > Can we all agree then, that for the list posted in your email above, any github
> > environmental feature can be recreated with proper tooling, available today,
> > without forcing the github environment on everybody?  Further, can we agree
> > that, given that those features are not unique to github, they are not
> > compelling reasons to move the project there?
> 
> Neil (I had to type this on my phone so please forgive any typos or other statements that may sound odd. I am not trying to be rude in anyway)
> 
> I feel you are taking everything out of context here. The email client being able collapse threads is not the point here and I have tried to redirect you politely to the points moving DPDK to github. 
> 
I'm sorry, I disagree.  This is the context in which we began this debate:
http://dpdk.org/ml/archives/dev/2015-May/017229.html

Matthew stated (and you supported) the notion that collapsing quotes in email
was an adventageous feature to have when reviewing patches.  While that may be
true for you (I certainly don't deny it), Everything I have said so far has been
an effort to illustrate that that feature (and more generally the workflow tools
that github provides) are reproducible using existing infrastructure and tools
(i.e. that the github environment is not a reason in and of itself to move to
github, as it is not unique to that environment).  I have pointed this out
several times:

http://dpdk.org/ml/archives/dev/2015-May/017233.html
http://dpdk.org/ml/archives/dev/2015-May/017247.html

Its you and Matthew that seem to be fixed on asserting that I'm somehow
focused on only choosing a mail client 

http://dpdk.org/ml/archives/dev/2015-May/017294.html

And I don't appreciate it.  You and Matthew made statements regarding this as a
feature that you found desierable (among other features).  I'm fine with you
doing so, and I believe that they are worthwhile points of debate.  What I am
unwilling to accept however, is that any assertion to the contrary is, to use
your words "not the point".  If you want to make a statement about the
superiority of a environment, please do so, but understand that there may be
those who don't agree.  If you don't want to have the argument, retract the
statement.

However, as I stated above more than once now, if we can agree that githubs
environment is not unique to github and so not a supporting reason to move the
project there, we can be done with this subthread in its entirety.

Note that I am not saying here that the tools and workflow that github provides
are expressly bad, only that they are not unique to github, and so other reasons
should be considered for the movement.

> As I and others have pointed out GitHub offers a huge number eyes for DPDK community. GitHub offers a different set of processes and tools, which we do not have to create. Moving to GitHub is a change for the community and I feel a good change for the better. 
> 

Ok, this is a a better reason to consider: Participant attention.  So far in
other discussion surrounding lack of uptake in developer participation in DPDK,
the focus has been on ways we can improve the existing community though process
changes.  What your proposing suggests here that the larger problem is not so
much process (though I'm sure thats on your mind too), but rather simple
numbers. More people == more developers.  That could be, I honestly don't know.
Fortunately that is a measureable, solvable problem.  I'd suggest that 6wind
enable analytics for the dpdk.org site so that we can get an idea of how much
visibility the site currently gets, and that would lead us to making a more
informed decision regarding if, and where the site would be better positioned.

> For your statements above I say NO we do not agree as much as your arguments around a single feature of an email client is not a compelling reason to accept your statements. 
> 
So you're back to arguing about email clients?  Please make a choice.  Either we
debate weather or not the github environment is adventageous, or we don't.  If
you want to debate it thats fine, but my stand is that the tools github provides
are not unique to github and can be implemented with our current environment
easily, if developers individaually choose to.  If you don't want to continue
debting it, I suppose thats fine too, but I presume you wish to do that because
you don't feel like the environment is a point worth arguing over (weather or
not we agree) on it being a non-differentiatior to other setups?

> Github gives us the DPDK community a better and more widely accepted place to allow DPDK to grow and become the open source project we all want IMO. 
> 
I'm not sure I can parse this.  What do you mean by "better" and "widely
accepted"?  Are you referring to your earlier statements regarding DPDK.org
being owned by 6wind?  I think that was you that said that (If not I apologize).
If thats the case, I think thats a reasonable argument to make, though I've not
gotten the impression (anecdotally of course) that current developers are
worried about that.  If there is generally concern over dpdk.org being owned by
a major contributor, I'd appreciate them speaking up here, as I think that would
be valuabe information to have.


> I want to be polite here and we are not going to agree with keeping DPDK as it is today. We need to grow and change is the only way, I believe moving to GitHub gives the best support and eyeballs on DPDK to grow. 
> 
Please understand, I'm not in favor of keeping everything exactly the same, far
from it.  I think there are many process issues that need to be worked out with
the community (review latency, patch application latency, subtree architecture
and maintenence, etc), but I think we can handle those issues incrementally,
with existing tools and within the existing community.  I feel as though a move
to github (or another hosted site to manage our process) is overkill for the
problems we have identified currently.

> The tools supported on GitHub are different and yes you may need to change. The day to day development will remain the same and as we know that is the bulk of the work. The pushing of patches will change, which should be easier for move people to understand plus use. 
> o

Yes, Assuming that we make the change.  But clearly we still have lots of debate
around weather or not thats a remotely good idea.

> We could spend a lot of time and money to update the current system, but why when we could start the move to GitHub today and use those tools for free. 
> 
Becuase you're considering the move to be "free".  How many developers do you
loose who prefer the current method of development?  How many man hours do you
spend setting up the environment, moving the code, getting all the current
participants integrated to the new system, and figuring out the new workflow?
For that matter, how much time do you think needs investing in updating the
current system?  I would argue from an infrastructure standpoint, not that much,
though again, thats probably a question to ask of 6wind, who continues to be
silent here.  I'd really like to hear from someone there about their willingness
to add people/trees to dpdk.org.
 

> I do not want this to become a flame war or something like it. I want us to try and figure out how we can improve the DPDK community. I can see keeping DPDK the way it is today, but this will stagnate DPDK IMHO and no one wants this to happen. 
Stagnates a scary word, but what evidence do you have that its truly
stagnating?  Based on raw numbers, the community is growing, just not as quickly
as some would like, the reasons for which have been at least partially
ennumerated on this list.  I think if we continue to discuss incremental process
changes, we don't need to do something as drastic as move the code repository
in its entirety (and incur all the process changes that come with it).

> 
> I do not want to split the DPDK community or try alienating any one. 
> 

No one does.

> Please take a breath and relax as we all want the best for DPDK. 
> 
Please do not try to position me as somehow angry here.  I'm debating your
assertions.  If you dont' want debate, don't participate.

Regards
Neil

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

[Wiles, Keith]

Neil and John and anyone else, if I have been rude or ugly in anyway that was not my intent. Please accept my apologies for being rude or condescending.

Sent from my iPhone

>> On May 5, 2015, at 12:07 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>> 
>> On Tue, May 05, 2015 at 04:43:08PM +0000, Wiles, Keith wrote:
>> 
>> 
>> Sent from my iPhone
>> 
>>>>> On May 5, 2015, at 6:56 AM, Neil Horman <nhorman@tuxdriver.com> wrote:
>>>> 
>>>>> On Mon, May 04, 2015 at 10:25:00PM -0500, Jim Thompson wrote:
>>>>> 
>>>>> On May 4, 2015, at 10:12 PM, Wiles, Keith <keith.wiles@intel.com> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>>> On 5/4/15, 10:48 AM, "Matthew Hall" <mhall@mhcomputing.net> wrote:
>>>>>>> 
>>>>>>> On Mon, May 04, 2015 at 12:43:48PM +0000, Qiu, Michael wrote:
>>>>>>> What mail client do you use? I think  mail client supporting thread mode
>>>>>>> is important for patch review.
>>>>>> 
>>>>>> Like many UNIX people, I use mutt.
>>>>>> 
>>>>>> My concern is that, if we're making the widespread adoption, usage, and
>>>>>> contributions for DPDK dependent on selection or debate of the features
>>>>>> of 
>>>>>> various MUAs, I'm not sure that we're looking at this from the right
>>>>>> angle.
>>>>>> 
>>>>>> I'm just trying to figure out how to get DPDK in the place where the most
>>>>>> eyeballs are, rather than trying to drag the eyeballs to the place where
>>>>>> DPDK 
>>>>>> is.
>>>>> 
>>>>> +1, I agree with this statement completely and I feel discussions about an
>>>>> MUA is non-productive and out of scope.
>>>> 
>>>> +1.  I’ve avoided the whole discussion, because … ok, “non-productive and out of scope” is a polite way of saying it.
>>>> 
>>>> jim
>>> 
>>> Very well, since you seem to want to avoid talking about ways to get what you
>>> want in a workflow, lets go back to where the conversation started:
>>> 
>>> http://dpdk.org/ml/archives/dev/2015-May/017225.html
>>> 
>>> We got into this debate because you wanted to move the project to github, and as
>>> supporting reasons, listed a plethora of features that you liked about the site.
>>> This entire subtread has been meant to illustrate how you can have the features
>>> you want that you see as adventageous in the github environment without actualy
>>> moving to github.  We've focused on email quote collapsing because we kept
>>> responding to one another, though I'm sure we could have the same debate on any
>>> one of the workflow features github offers.
>>> 
>>> Can we all agree then, that for the list posted in your email above, any github
>>> environmental feature can be recreated with proper tooling, available today,
>>> without forcing the github environment on everybody?  Further, can we agree
>>> that, given that those features are not unique to github, they are not
>>> compelling reasons to move the project there?
>> 
>> Neil (I had to type this on my phone so please forgive any typos or other statements that may sound odd. I am not trying to be rude in anyway)
>> 
>> I feel you are taking everything out of context here. The email client being able collapse threads is not the point here and I have tried to redirect you politely to the points moving DPDK to github.
> I'm sorry, I disagree.  This is the context in which we began this debate:
> http://dpdk.org/ml/archives/dev/2015-May/017229.html
> 
> Matthew stated (and you supported) the notion that collapsing quotes in email
> was an adventageous feature to have when reviewing patches.  While that may be
> true for you (I certainly don't deny it), Everything I have said so far has been
> an effort to illustrate that that feature (and more generally the workflow tools
> that github provides) are reproducible using existing infrastructure and tools
> (i.e. that the github environment is not a reason in and of itself to move to
> github, as it is not unique to that environment).  I have pointed this out
> several times:
> 
> http://dpdk.org/ml/archives/dev/2015-May/017233.html
> http://dpdk.org/ml/archives/dev/2015-May/017247.html
> 
> Its you and Matthew that seem to be fixed on asserting that I'm somehow
> focused on only choosing a mail client

I am sorry if I seem to be doing what you suggest. I agree and email client feature is not a valid reason to move. To me it was a minor point and me moving to another email client with that feature was not a reasonable solution for me. I was trying to move to other topics as I felt we both made our statements I guess a responded wrong. 

> http://dpdk.org/ml/archives/dev/2015-May/017294.html
> 
> And I don't appreciate it.  You and Matthew made statements regarding this as a
> feature that you found desierable (among other features).  I'm fine with you
> doing so, and I believe that they are worthwhile points of debate.  What I am
> unwilling to accept however, is that any assertion to the contrary is, to use
> your words "not the point".  If you want to make a statement about the
> superiority of a environment, please do so, but understand that there may be
> those who don't agree.  If you don't want to have the argument, retract the
> statement.

Your point is taken to heart. 

> 
> However, as I stated above more than once now, if we can agree that githubs
> environment is not unique to github and so not a supporting reason to move the
> project there, we can be done with this subthread in its entirety.
> 
> Note that I am not saying here that the tools and workflow that github provides
> are expressly bad, only that they are not unique to github, and so other reasons
> should be considered for the movement.
> 
>> As I and others have pointed out GitHub offers a huge number eyes for DPDK community. GitHub offers a different set of processes and tools, which we do not have to create. Moving to GitHub is a change for the community and I feel a good change for the better.
> 
> Ok, this is a a better reason to consider: Participant attention.  So far in
> other discussion surrounding lack of uptake in developer participation in DPDK,
> the focus has been on ways we can improve the existing community though process
> changes.  What your proposing suggests here that the larger problem is not so
> much process (though I'm sure thats on your mind too), but rather simple
> numbers. More people == more developers.  That could be, I honestly don't know.
> Fortunately that is a measureable, solvable problem.  I'd suggest that 6wind
> enable analytics for the dpdk.org site so that we can get an idea of how much
> visibility the site currently gets, and that would lead us to making a more
> informed decision regarding if, and where the site would be better positioned.

We can enable the analytics for the site, but the numbers are more subjective and may not gives us much but we should do it. 

Github has the eyes and personally I tend to go to the GitHub site first if I see it on a Google search as it seems to be a safer place to find what I need. 

One area I would like to see around how users can work together in a location I see as more of an open place for us to collaborate. Maybe I see this as a problem and no one else does. 

Being able to have a bit more structure around committers and teams to work together on a specific repo within the community. GitHub has this in place today and it would be nice to use these tools.

Managing commiters, owners and teams is already in place on GitHub. 

> 
>> For your statements above I say NO we do not agree as much as your arguments around a single feature of an email client is not a compelling reason to accept your statements.
> So you're back to arguing about email clients?  Please make a choice.  Either we
> debate weather or not the github environment is adventageous, or we don't.  If
> you want to debate it thats fine, but my stand is that the tools github provides
> are not unique to github and can be implemented with our current environment
> easily, if developers individaually choose to.  If you don't want to continue
> debting it, I suppose thats fine too, but I presume you wish to do that because
> you don't feel like the environment is a point worth arguing over (weather or
> not we agree) on it being a non-differentiatior to other setups?

I know we could change the site to fit our needs, but is that a reasonable solution as I see GitHub has these already. Maybe I am throwing the baby out with the bath water, but it does not feel like it to me. 

> 
>> Github gives us the DPDK community a better and more widely accepted place to allow DPDK to grow and become the open source project we all want IMO.
> I'm not sure I can parse this.  What do you mean by "better" and "widely
> accepted"?  Are you referring to your earlier statements regarding DPDK.org
> being owned by 6wind?  I think that was you that said that (If not I apologize).
> If thats the case, I think thats a reasonable argument to make, though I've not
> gotten the impression (anecdotally of course) that current developers are
> worried about that.  If there is generally concern over dpdk.org being owned by
> a major contributor, I'd appreciate them speaking up here, as I think that would
> be valuabe information to have.

Yes I agree hearing from others would be great. I have heard third hand and that is where my concerns come from, which is not good is some respects. 

> 
> 
>> I want to be polite here and we are not going to agree with keeping DPDK as it is today. We need to grow and change is the only way, I believe moving to GitHub gives the best support and eyeballs on DPDK to grow.
> Please understand, I'm not in favor of keeping everything exactly the same, far
> from it.  I think there are many process issues that need to be worked out with
> the community (review latency, patch application latency, subtree architecture
> and maintenence, etc), but I think we can handle those issues incrementally,
> with existing tools and within the existing community.  I feel as though a move
> to github (or another hosted site to manage our process) is overkill for the
> problems we have identified currently.
> 
>> The tools supported on GitHub are different and yes you may need to change. The day to day development will remain the same and as we know that is the bulk of the work. The pushing of patches will change, which should be easier for move people to understand plus use. 
>> o
> 
> Yes, Assuming that we make the change.  But clearly we still have lots of debate
> around weather or not thats a remotely good idea.
> 
>> We could spend a lot of time and money to update the current system, but why when we could start the move to GitHub today and use those tools for free.
> Becuase you're considering the move to be "free".  How many developers do you
> loose who prefer the current method of development?  How many man hours do you
> spend setting up the environment, moving the code, getting all the current
> participants integrated to the new system, and figuring out the new workflow?

I see the current day to day workflow does not change setting up the github account and forking the repo is easy. All of the processes after that point up to pushing to the master should be same at least I have not detected any difference. 

> For that matter, how much time do you think needs investing in updating the
> current system?  I would argue from an infrastructure standpoint, not that much,
> though again, thats probably a question to ask of 6wind, who continues to be
> silent here.  I'd really like to hear from someone there about their willingness
> to add people/trees to dpdk.org.

+1

> 
>> I do not want this to become a flame war or something like it. I want us to try and figure out how we can improve the DPDK community. I can see keeping DPDK the way it is today, but this will stagnate DPDK IMHO and no one wants this to happen.
> Stagnates a scary word, but what evidence do you have that its truly
> stagnating?  Based on raw numbers, the community is growing, just not as quickly
> as some would like, the reasons for which have been at least partially
> ennumerated on this list.  I think if we continue to discuss incremental process
> changes, we don't need to do something as drastic as move the code repository
> in its entirety (and incur all the process changes that come with it).

Stagnate is a strong word and it was not the best way state it. I want the site to be more friendly to others not just the command line guys like me. 

> 
>> 
>> I do not want to split the DPDK community or try alienating any one.
> 
> No one does.
> 
>> Please take a breath and relax as we all want the best for DPDK.
> Please do not try to position me as somehow angry here.  I'm debating your
> assertions.  If you dont' want debate, don't participate.
> 
> Regards
> Neil
> 

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

[Panu Matilainen]

On 05/05/2015 07:43 PM, Wiles, Keith wrote:
>
>
> Sent from my iPhone
>
>> On May 5, 2015, at 6:56 AM, Neil Horman <nhorman@tuxdriver.com> wrote:
>>
>>> On Mon, May 04, 2015 at 10:25:00PM -0500, Jim Thompson wrote:
>>>
>>>> On May 4, 2015, at 10:12 PM, Wiles, Keith <keith.wiles@intel.com> wrote:
>>>>
>>>>
>>>>
>>>>> On 5/4/15, 10:48 AM, "Matthew Hall" <mhall@mhcomputing.net> wrote:
>>>>>
>>>>>> On Mon, May 04, 2015 at 12:43:48PM +0000, Qiu, Michael wrote:
>>>>>> What mail client do you use? I think  mail client supporting thread mode
>>>>>> is important for patch review.
>>>>>
>>>>> Like many UNIX people, I use mutt.
>>>>>
>>>>> My concern is that, if we're making the widespread adoption, usage, and
>>>>> contributions for DPDK dependent on selection or debate of the features
>>>>> of
>>>>> various MUAs, I'm not sure that we're looking at this from the right
>>>>> angle.
>>>>>
>>>>> I'm just trying to figure out how to get DPDK in the place where the most
>>>>> eyeballs are, rather than trying to drag the eyeballs to the place where
>>>>> DPDK
>>>>> is.
>>>>
>>>> +1, I agree with this statement completely and I feel discussions about an
>>>> MUA is non-productive and out of scope.
>>>
>>> +1.  I’ve avoided the whole discussion, because … ok, “non-productive and out of scope” is a polite way of saying it.
>>>
>>> jim
>>
>> Very well, since you seem to want to avoid talking about ways to get what you
>> want in a workflow, lets go back to where the conversation started:
>>
>> http://dpdk.org/ml/archives/dev/2015-May/017225.html
>>
>> We got into this debate because you wanted to move the project to github, and as
>> supporting reasons, listed a plethora of features that you liked about the site.
>> This entire subtread has been meant to illustrate how you can have the features
>> you want that you see as adventageous in the github environment without actualy
>> moving to github.  We've focused on email quote collapsing because we kept
>> responding to one another, though I'm sure we could have the same debate on any
>> one of the workflow features github offers.
>>
>> Can we all agree then, that for the list posted in your email above, any github
>> environmental feature can be recreated with proper tooling, available today,
>> without forcing the github environment on everybody?  Further, can we agree
>> that, given that those features are not unique to github, they are not
>> compelling reasons to move the project there?
>
> Neil (I had to type this on my phone so please forgive any typos or
> other statements that may sound odd. I am not trying to be rude in anyway)

Somewhat OT but if you feel a disclaimer like this is required, would it 
not be better to let the response wait a few hours (or even a day or 
two) until you get back to a real computer? Especially since the matter 
is not actually urgent but just an ongoing discussion on a mailing list 
that is likely to continue for days or weeks to come.

>
> I feel you are taking everything out of context here. The email
> client being able collapse threads is not the point here and I have
> tried to redirect you politely to the points moving DPDK to github.

Well perhaps there's also a point between the lines: many people (myself 
included) prefer email with the MUA of their choice as *the* tool for 
these tasks over some web interface that changes every now and then at 
somebody elses whim. But certainly many != all.

> As I and others have pointed out GitHub offers a huge number eyes
> for DPDK community.

I dont know - how does moving a tree into a forest make it more visible? 
Well, to some of the other trees in the forest yes. Maybe there's a 
social networking aspect to this which I dont understand, I'm just a 
grumpy old-schooler. But if I need to find something, be it software or 
something else, I go to Google not GitHub (or SourceForge before that).

> GitHub offers a different set of processes and
> tools, which we do not have to create. Moving to GitHub is a change
> for the community and I feel a good change for the better.

Like quite a few others in this thread, I dont care if the git repo 
moved to the end of internet as long as email continues to be a 
first-class means for patch submissions, reviews and other 
communication. It doesn't have to be the only way as clearly many people 
prefer otherwise.

[...]
>
> I do not want to split the DPDK community or try alienating any one.

Forcing a change of tools and workflows on everybody WILL create 
ill-will if nothing else.

Also please realize that not everybody sees GitHub as the greatest thing 
since sliced bread. It has quite some "Hotel California" aspects to it, 
and actually the imago of an average GH project is not that great: there 
are so many badly run and abandoned projects there that the first 
thought when I hear the word GitHub is "oh no, not one of those again" 
rather than "cool". I know I'm not alone in that thinking.

	- Panu -

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

[Simon Kågström]

On 2015-05-06 10:12, Panu Matilainen wrote:
> On 05/05/2015 07:43 PM, Wiles, Keith wrote:
>
>> GitHub offers a different set of processes and
>> tools, which we do not have to create. Moving to GitHub is a change
>> for the community and I feel a good change for the better.
> 
> Like quite a few others in this thread, I dont care if the git repo
> moved to the end of internet as long as email continues to be a
> first-class means for patch submissions, reviews and other
> communication. It doesn't have to be the only way as clearly many people
> prefer otherwise.

Perhaps something like pull-request-mailer could be used to tend to both
camps? I.e., sending out github pull requests to the mailing list for
review:

  https://github.com/google/pull-request-mailer

Anyway, for me personally (as a DPDK outsider), what I feel would be the
main improvement with using github would be that they have a very
well-integrated bug reporting system that keeps track of e.g., the
commit that fixes the bug etc.

I recently submitted a build issue to the mailing list, which Olivier
Matz promptly fixed with a patch (but which haven't been merged as far
as I can tell). In the gihub workflow, I'd submitted a bug report
("Issue #13" for example), Olivier would have fixed this through a
merge-request ("Issue #13: scripts: fix relpath.sh output when build dir
is a symlink") and I'd acked that fix in the bug report. When the merge
request was merged to the git repo, the bug report would be closed.


I'm also interested in the architecture discussions etc (or the github
debate!) on the list, but I really don't read patches sent to the list.


So if I had a vote (which I shouldn't have :-)), I'd vote for a gradual
move to github and a mailing list split.

// Simon

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

[Panu Matilainen]

On 05/06/2015 11:30 AM, Simon Kågström wrote:
> On 2015-05-06 10:12, Panu Matilainen wrote:
>> On 05/05/2015 07:43 PM, Wiles, Keith wrote:
>>
>>> GitHub offers a different set of processes and
>>> tools, which we do not have to create. Moving to GitHub is a change
>>> for the community and I feel a good change for the better.
>>
>> Like quite a few others in this thread, I dont care if the git repo
>> moved to the end of internet as long as email continues to be a
>> first-class means for patch submissions, reviews and other
>> communication. It doesn't have to be the only way as clearly many people
>> prefer otherwise.
>
> Perhaps something like pull-request-mailer could be used to tend to both
> camps? I.e., sending out github pull requests to the mailing list for
> review:
>
>    https://github.com/google/pull-request-mailer
>
> Anyway, for me personally (as a DPDK outsider), what I feel would be the
> main improvement with using github would be that they have a very
> well-integrated bug reporting system that keeps track of e.g., the
> commit that fixes the bug etc.
>
> I recently submitted a build issue to the mailing list, which Olivier
> Matz promptly fixed with a patch (but which haven't been merged as far
> as I can tell). In the gihub workflow, I'd submitted a bug report
> ("Issue #13" for example), Olivier would have fixed this through a
> merge-request ("Issue #13: scripts: fix relpath.sh output when build dir
> is a symlink") and I'd acked that fix in the bug report. When the merge
> request was merged to the git repo, the bug report would be closed.

Okay, there's a solid technical point in favor of GitHub, there haven't 
been too many of those in this thread.

Of course there are any number of bug/issue trackers out there but the 
current lack of bug tracking system beyond email for DPDK is somewhat 
disconcerting.

>
> I'm also interested in the architecture discussions etc (or the github
> debate!) on the list, but I really don't read patches sent to the list.
>
>
> So if I had a vote (which I shouldn't have :-)), I'd vote for a gradual
> move to github and a mailing list split.

One simple way to increase visibility on GH without affecting anything 
(so should be mostly harmless) else might be creating an official 
read-only mirror in there like various "big name" projects have done:
https://help.github.com/articles/about-github-mirrors/

	- Panu -

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

[Neil Horman]

On Wed, May 06, 2015 at 10:30:04AM +0200, Simon Kågström wrote:
> On 2015-05-06 10:12, Panu Matilainen wrote:
> > On 05/05/2015 07:43 PM, Wiles, Keith wrote:
> >
> >> GitHub offers a different set of processes and
> >> tools, which we do not have to create. Moving to GitHub is a change
> >> for the community and I feel a good change for the better.
> > 
> > Like quite a few others in this thread, I dont care if the git repo
> > moved to the end of internet as long as email continues to be a
> > first-class means for patch submissions, reviews and other
> > communication. It doesn't have to be the only way as clearly many people
> > prefer otherwise.
> 
> Perhaps something like pull-request-mailer could be used to tend to both
> camps? I.e., sending out github pull requests to the mailing list for
> review:
> 
>   https://github.com/google/pull-request-mailer
> 

FWIW, I'm the irqbalance maintainer, and I use github for that project, because
its super low volume at this point (i.e. its mature, and doesn't really need a
mailing list).  That said, I am investigating the above mail bridge utility for
that project and will let you all know the results.
Neil

> Anyway, for me personally (as a DPDK outsider), what I feel would be the
> main improvement with using github would be that they have a very
> well-integrated bug reporting system that keeps track of e.g., the
> commit that fixes the bug etc.
> 
> I recently submitted a build issue to the mailing list, which Olivier
> Matz promptly fixed with a patch (but which haven't been merged as far
> as I can tell). In the gihub workflow, I'd submitted a bug report
> ("Issue #13" for example), Olivier would have fixed this through a
> merge-request ("Issue #13: scripts: fix relpath.sh output when build dir
> is a symlink") and I'd acked that fix in the bug report. When the merge
> request was merged to the git repo, the bug report would be closed.
> 
> 
> I'm also interested in the architecture discussions etc (or the github
> debate!) on the list, but I really don't read patches sent to the list.
> 
> 
> So if I had a vote (which I shouldn't have :-)), I'd vote for a gradual
> move to github and a mailing list split.
> 
> // Simon
> 

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

[John W. Linville]

On Wed, May 06, 2015 at 11:12:28AM +0300, Panu Matilainen wrote:

> Forcing a change of tools and workflows on everybody WILL create ill-will if
> nothing else.
> 
> Also please realize that not everybody sees GitHub as the greatest thing
> since sliced bread. It has quite some "Hotel California" aspects to it, and
> actually the imago of an average GH project is not that great: there are so
> many badly run and abandoned projects there that the first thought when I
> hear the word GitHub is "oh no, not one of those again" rather than "cool".
> I know I'm not alone in that thinking.

GitHub -- the SourceForge of the 21st century!

-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

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

[Wiles, Keith]

On 5/1/15, 11:45 AM, "Neil Horman" <nhorman@tuxdriver.com> wrote:

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

Google is a great tool, you can find anything in the world with Google and
will continue to be how most find items on the web. Being able to use
Google is not the right question here you should be asking.

The question is how do we promote and get higher visitability for the DPDK
community? I believe moving DPDK.org to a well known location and a well
known open source location should be a benefit for the DPDK community as a
whole. If you are using GitHub today then I think you understand this
point already.

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

Private repos (5) of them come for free and I pointed out the only reason
I thought we needed one as a temporary place for a repo before making
public. I agree we do not really need them and all repos should be public.

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

Maybe you mis-read this point. I am not suggesting only one committer,
what I am suggesting is adding committers and logins to a 6Wind controlled
machine could be a security issue for 6Wind. Maybe not, but moving to
GitHub removes any possible hacks to 6Wind is my belief and possible
liability issues for 6Wind. This was a very minor point.


As for multiple subtrees can quickly and easily be added to GitHub and you
could even make this happen if you want to be one of the persons helping
build the GitHub site. From other GitHub sites I see a lot of repos and
sub repos to the primary tree and personally I agree having a few more
subtrees will not effect DPDK and could possible help define teams around
these subtrees.

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

I do not believe the point is around if 6Wind loans us machines and
storage and internet connect bandwidth. My point is GitHub is big company
and they have a lot of resources to make sure everyone remains connected
to the repo(s), Backups, support, tools and any number of other items to
make the DPDK community better in the long run. I believe it comes down to
resources and freeing up resources for 6Wind by moving to a bigger company
which is its sole job is to host sites like this one.

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

I agree, but I can not tell 6Wind to discontinue its site, that would not
be right all I can do is make sure we promote the correct open source
location for DPDK community.

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

GitHub has different permission levels (4 of them) and any number of teams
we can use to manage how the repos/site can be managed around how we allow
access to repos along with which team you belong. Currently 6Wind is the
sole owner of the site, but with GitHub we can have as many owners of the
site we need. Placing more then one person/company at this level seems
reasonable as this is a community of people/companies. Using the other
permission levels gives us a few more options. Personally having everyone
or only one as the owner is not have will help the community.

I personally do not want to be an owner of the DPDK repo, but a
contributor to that repo. The owner has some permissions that we would not
want everyone to be able to change, but if that is what everyone wants I
am OK with it. Being on a team for Pktgen with admin permissions seems
reasonable along with anyone else that would like admin rights.

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

I could enumerate on my personal issues with patchwork, but the point is
we would not require patchwork using GitHub and the process/tools on
GitHub are maintained my GitHub.

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

I was playing with the patch process on GitHub and it does provide a good
way to manage discussions and inlining comments directly or overall to a
patch.

I understand moving from a email base solution to GitHub maybe a change,
but it affords a lot more IMO.

I just read Matthew’s response and he stated the issues for me very well +1

―――――――― Pasted from Matthew’s email
Normally I'm a big command-line supporter. However I have found reviewing
patches by email for me is about the most painful workflow.

The emails are pages and pages.

The replies from commenters are buried in the walls of text.

Replies to replies keep shifting farther off the edge of the screen. The
code 
gets weirder and weirder to try to read.

Quickly reading over the patchset by scrolling through to get the flavor
of 
it, to see if I'm qualified to review it, and look at the parts I actually
know about is much harder.

I can go to one place to see every candidate patchset out there, the GH
Pull 
Request page. Then I can just sync up the branch and test it on my own
systems 
to see if it works, not just try to read it.

Github automatically minimizes old comments that are already fixed, so
they 
don't keep consuming space and mental bandwidth from the review.

All in all, I'd be able to review more DPDK patches faster with the GH
interface than having them in the mailing list.

Matthew.
――――――――

Sometimes people can snip and modify emails as they are sent/replied and
to me that can lead to re-writing history or points of view. Not a big
concern here on this list.

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

A well known public site managed by a company as its sole reason to exist
makes it easier for two or more persons to find each other and collaborate
IMO.

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

In GitHub you can create a team and set the permissions for the members of
that team to better control that repo while still make it publicly
available to others at a read only. The others to not have to find the
email address join, then search wildly in the history to find commits,
patches and discussions around that repo or patch.

GitHub makes this process easier and it is not perfect, but better then an
email thread and will help the community I believe.

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

Please visit the GitHub docs for more details as I do not need to list
them here and would just deflect the discussion in the wrong direction.
https://help.github.com/


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

I agree, but again I can not tell 6Wind what to do with its email list and
the email list may still be reasonable. Maybe someone else can suggest a
solution to this issue and how it was solved in other GitHub open source
projects.

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

I believe if you look at it from the community point of view it may make
more sense to you at least it does to me.

>
>Neil

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

[Stephen Hemminger]

On Fri, 1 May 2015 15:56:32 +0000
"Wiles, Keith" <keith.wiles@intel.com> wrote:

> Hi Everyone,
> 
> I believe the DPDK community would benefit from moving to GitHub as the
> primary DPDK site. http://github.com
> 
> 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.
> 
> 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.
> 
> 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).
> - 6Wind appearing to own DPDK.org is not a good message to the community.
>   - 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.
> - Permission and access levels in dpdk.org is only one level and we can
> benefit from having 4 levels and teams as well.
> - 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.
>   - 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 :-)
> - GitHub has team support and gives a group better control plus
> collaboration is much easier as we have a external location to work.
>   - 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.
>   - Using GitHub and teams would make collaboration a lot easier or
> collaboration between two or more user accounts as well.
> - GitHub has a Web Page system, which can be customized for the community
> needs via a public or private repo.
> - 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
> appended to the discussion thread.
> 

In my experience the github pull model causes less review, not more.
It only works if maintainers are motivated to do this as their full time job.

With email, the patches are right in front of developers and easier to quote
for review comments.

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

[Wiles, Keith]

On 5/1/15, 1:09 PM, "Stephen Hemminger" <stephen@networkplumber.org> wrote:

>On Fri, 1 May 2015 15:56:32 +0000
>"Wiles, Keith" <keith.wiles@intel.com> wrote:
>
>> Hi Everyone,
>> 
>> I believe the DPDK community would benefit from moving to GitHub as the
>> primary DPDK site. http://github.com
>> 
>> 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.
>> 
>> 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.
>> 
>> 
>>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).
>> - 6Wind appearing to own DPDK.org is not a good message to the
>>community.
>>   - 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.
>> - Permission and access levels in dpdk.org is only one level and we can
>> benefit from having 4 levels and teams as well.
>> - 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.
>>   - 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 :-)
>> - GitHub has team support and gives a group better control plus
>> collaboration is much easier as we have a external location to work.
>>   - 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.
>>   - Using GitHub and teams would make collaboration a lot easier or
>> collaboration between two or more user accounts as well.
>> - GitHub has a Web Page system, which can be customized for the
>>community
>> needs via a public or private repo.
>> - 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
>> appended to the discussion thread.
>> 
>
>In my experience the github pull model causes less review, not more.
>It only works if maintainers are motivated to do this as their full time
>job.
>
>With email, the patches are right in front of developers and easier to
>quote
>for review comments.

We are not getting the eyes on the review today, which means to me it will
not matter if we move to GitHub method in the future.

Personally I am able to see the differences with the GitHub display and
helps me see what is really happening. The emails are too flat and then
they can indent forever or someones email client (like mine) screws up the
format. With the GitHub method is will be exactly the same for everyone.

>

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

[Marc Sune]

On 01/05/15 20:17, Wiles, Keith wrote:
>
> On 5/1/15, 1:09 PM, "Stephen Hemminger" <stephen@networkplumber.org> wrote:
>
>> On Fri, 1 May 2015 15:56:32 +0000
>> "Wiles, Keith" <keith.wiles@intel.com> wrote:
>>
>>> Hi Everyone,
>>>
>>> I believe the DPDK community would benefit from moving to GitHub as the
>>> primary DPDK site. http://github.com
>>>
>>> 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.
>>>
>>> The cost for an organization account is $0 as long as we do not need
>>> more
>>> then 5 private repos.

Minor issue:

https://github.com/pricing

Private repos for both users and organizations are not for free in
github (they've never been afaik). They are in bitbucket, up to 5
contributors.

But I don't get how private repositories have any influence in this
discussion. Private repositories will be owned by companies and not DPDK
as a community anyway.

marc

>>>  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.
>>>
>>>
>>> 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).
>>> - 6Wind appearing to own DPDK.org is not a good message to the
>>> community.
>>>   - 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.
>>> - Permission and access levels in dpdk.org is only one level and we can
>>> benefit from having 4 levels and teams as well.
>>> - 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.
>>>   - 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 :-)
>>> - GitHub has team support and gives a group better control plus
>>> collaboration is much easier as we have a external location to work.
>>>   - 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.
>>>   - Using GitHub and teams would make collaboration a lot easier or
>>> collaboration between two or more user accounts as well.
>>> - GitHub has a Web Page system, which can be customized for the
>>> community
>>> needs via a public or private repo.
>>> - 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
>>> appended to the discussion thread.
>>>
>> In my experience the github pull model causes less review, not more.
>> It only works if maintainers are motivated to do this as their full time
>> job.
>>
>> With email, the patches are right in front of developers and easier to
>> quote
>> for review comments.
> We are not getting the eyes on the review today, which means to me it will
> not matter if we move to GitHub method in the future.
>
> Personally I am able to see the differences with the GitHub display and
> helps me see what is really happening. The emails are too flat and then
> they can indent forever or someones email client (like mine) screws up the
> format. With the GitHub method is will be exactly the same for everyone.
>

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

[Wiles, Keith]

On 5/4/15, 1:34 PM, "Marc Sune" <marc.sune@bisdn.de> wrote:

>
>
>On 01/05/15 20:17, Wiles, Keith wrote:
>>
>> On 5/1/15, 1:09 PM, "Stephen Hemminger" <stephen@networkplumber.org>
>>wrote:
>>
>>> On Fri, 1 May 2015 15:56:32 +0000
>>> "Wiles, Keith" <keith.wiles@intel.com> wrote:
>>>
>>>> Hi Everyone,
>>>>
>>>> I believe the DPDK community would benefit from moving to GitHub as
>>>>the
>>>> primary DPDK site. http://github.com
>>>>
>>>> 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.
>>>>
>>>> The cost for an organization account is $0 as long as we do not need
>>>> more
>>>> then 5 private repos.
>
>Minor issue:
>
>https://github.com/pricing
>
>Private repos for both users and organizations are not for free in
>github (they've never been afaik). They are in bitbucket, up to 5
>contributors.

Sorry, I could have sworn they gave 5 free, but you are correct we should
not require any private repos as we can use the teams and permissions.

Odd did they always have a cost for private repos for personal accounts? I
was thinking I had gotten 5 free in the beginning, but I have had to move
up to 10 repos a 8 months ago and I forget.
>
>But I don't get how private repositories have any influence in this
>discussion. Private repositories will be owned by companies and not DPDK
>as a community anyway.
>
>marc
>
>>>>  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.
>>>>
>>>>
>>>> 
>>>>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).
>>>> - 6Wind appearing to own DPDK.org is not a good message to the
>>>> community.
>>>>   - 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.
>>>> - Permission and access levels in dpdk.org is only one level and we
>>>>can
>>>> benefit from having 4 levels and teams as well.
>>>> - 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.
>>>>   - 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 :-)
>>>> - GitHub has team support and gives a group better control plus
>>>> collaboration is much easier as we have a external location to work.
>>>>   - 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.
>>>>   - Using GitHub and teams would make collaboration a lot easier or
>>>> collaboration between two or more user accounts as well.
>>>> - GitHub has a Web Page system, which can be customized for the
>>>> community
>>>> needs via a public or private repo.
>>>> - 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
>>>> appended to the discussion thread.
>>>>
>>> In my experience the github pull model causes less review, not more.
>>> It only works if maintainers are motivated to do this as their full
>>>time
>>> job.
>>>
>>> With email, the patches are right in front of developers and easier to
>>> quote
>>> for review comments.
>> We are not getting the eyes on the review today, which means to me it
>>will
>> not matter if we move to GitHub method in the future.

Correct, we need to add a process to require reviews in some way, what
that process needs to be defined.

>>
>> Personally I am able to see the differences with the GitHub display and
>> helps me see what is really happening. The emails are too flat and then
>> they can indent forever or someones email client (like mine) screws up
>>the
>> format. With the GitHub method is will be exactly the same for everyone.

Moving to an easier reading display for everyone makes sense to me. Not
have to remember to add ―in-reply-to every time is also another reason to
adopt a system that handles this for you. Having a bunch of little
processes to manage is just asking for little mistakes and GitHub method
fixes this one.

Having everyone able to see the exact same style is the big plus that Marc
is pointing out here not what MUA someone uses.

>>
>

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

[Matthew Hall]

On Fri, May 01, 2015 at 11:09:14AM -0700, Stephen Hemminger wrote:
> With email, the patches are right in front of developers and easier to quote
> for review comments.

Right in front of that subset of developers who do everything kernel-style, 
perhaps yes. But this sort of workflow is in the minority these days, pretty 
much every other project I've worked on besides the kernel used graphical 
merging tools for this to make things easier to follow for the uninitiated.

The GH pull requests are more friendly to all the non-kernel-style developers 
we're saying in these threads that we are hoping to get more involved in DPDK. 

I use DPDK on purpose because I don't want the ultimate purpose of my 
application to be getting into the middle of huge hard-to-read hard-to-follow 
threads, core-kernel flamewars, hard-to-read weird 30-year-old network stack 
code, panics that take down my machine instead of debuggable core dump files, 
etc.

So I'm hoping we could get a patch review system that's more modernized. 
Something where anybody can easily read and quickly the patches without a 
bunch of email-client-specific headaches, and a sea of emails to be saved off 
and fed into git apply-patch, and branches ready-to-go for checkout for 
testing, review, and repatching if they have mistakes in them.

Having the branches published centrally enables a modernized DevOps style 
workflow, where I can grab a new branch, run some kind of Integration Test of 
the feature or even just experiments with it in my own code, and go back to 
the central place to report how it worked, what was right and what wasn't, 
even better, I can send along a PR to the PR branch, with more stuff it needs 
before it's safe to place into master.

Matthew.

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

[Aaro Koskinen]

On Fri, May 01, 2015 at 12:49:51PM -0700, Matthew Hall wrote:
> On Fri, May 01, 2015 at 11:09:14AM -0700, Stephen Hemminger wrote:
> > With email, the patches are right in front of developers and easier to quote
> > for review comments.
> 
> Right in front of that subset of developers who do everything kernel-style, 
> perhaps yes. But this sort of workflow is in the minority these days, pretty 
> much every other project I've worked on besides the kernel used graphical 
> merging tools for this to make things easier to follow for the uninitiated.

Projects like GCC, GLIBC, binutils, busybox, etc or what?

A.

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

[Matthew Hall]

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.

The most popular projects in Github have up to 80K watchers, and 100K forks. 
This type of popularity and interest is going to be hard to match just doing 
it the older way only. Even Google said so, when they shut down Google Code 
and moved stuff to Github:

http://google-opensource.blogspot.com/2015/03/farewell-to-google-code.html

If we want to shoot for a big audience we have to make sure we have a presence 
where the eyeballs are focused, as well as finding a way to support the 
traditional kernel-style workflow some of the core contributors use.

Matthew.

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

[Neil Horman]

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

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.

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

[Thomas F Herbert]

On 5/2/15 7:40 AM, Neil Horman 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.
A look at gmane, http://dir.gmane.org/gmane.comp.networking.dpdk.devel, 
confirms the explosion of interest in DPDK in the last 6 months with 
postings up to almost 70/day.  There is no problem with lack of interest 
in DPDK nor is there a need to change the mechanics of hosting the 
source to widen the audience. The case for DPDK is really compelling, 
the idea for reducing the HW complexity by accelerating switch functions 
on commodity HW is a fantastic benefit. Easily integrated accelerated 
programmable switch functions is a great advantage as well.

I do think there may be an argument for increasing the number of 
reviewers/maintainers or subdivide according to ares of interest perhaps 
into 4 categories:
1. PMD drivers
2. librte core
3. applications
4. vhost

--TFH

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


-- 
Thomas F. Herbert

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

[Wiles, Keith]

On 5/2/15, 7:37 AM, "Thomas F Herbert" <thomasfherbert@gmail.com> wrote:

>On 5/2/15 7:40 AM, Neil Horman 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.
>A look at gmane, http://dir.gmane.org/gmane.comp.networking.dpdk.devel,
>confirms the explosion of interest in DPDK in the last 6 months with
>postings up to almost 70/day.  There is no problem with lack of interest
>in DPDK nor is there a need to change the mechanics of hosting the

We do need to reach more developer as I see the DPDK community growing
around VNF/NFV to developers that are not experts in the fine details of
DPDK, but a group of developers wanting to get the highest performance out
of his NFV/VNF system.

The DPDK community needs to grow and will grow, at 70+ emails a day which
will only become more. Using something like GitHub we will be able to help
the DPDK community to become more then a niche project or a low level tool.

Moving to a new site helps us. I believe, it may not allow you to stay
using pure command line development, but we as developers can and will
adapt to the new process quickly as I see the DPDK community as a very
bright and resourceful group of developers.

> 
>source to widen the audience. The case for DPDK is really compelling,
>the idea for reducing the HW complexity by accelerating switch functions
>on commodity HW is a fantastic benefit. Easily integrated accelerated
>programmable switch functions is a great advantage as well.
>
>I do think there may be an argument for increasing the number of
>reviewers/maintainers or subdivide according to ares of interest perhaps
>into 4 categories:
>1. PMD drivers
>2. librte core
>3. applications
>4. vhost
>
>--TFH
>
>>>
>> 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
>>
>> 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.
>>
>
>
>-- 
>Thomas F. Herbert
>

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

[Wiles, Keith]

On 5/2/15, 6:40 AM, "Neil Horman" <nhorman@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.
>
>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.
>

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

[Marc Sune]

On 02/05/15 15:59, Wiles, Keith wrote:
>
> On 5/2/15, 6:40 AM, "Neil Horman" <nhorman@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.
>>

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

[Wiles, Keith]

Hi Marc

On 5/4/15, 2:08 PM, "Marc Sune" <marc.sune@bisdn.de> wrote:

>
>
>On 02/05/15 15:59, Wiles, Keith wrote:
>>
>> On 5/2/15, 6:40 AM, "Neil Horman" <nhorman@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.

To me this seems reasonable and we can work on this with the sandbox.

Need to play with it more, but I do not have a email list someplace to
play and write the bot. Lets talk more about this outside the list and if
someone else is wanting to help please let us know and we can add you to
the discussions.

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

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

[Simon Ka*gstro"m]

On 2015-05-01 17:56, Wiles, Keith wrote:
> I believe the DPDK community would benefit from moving to GitHub as the
> primary DPDK site. http://github.com
> [...]

While I'm really mostly a DPDK outsider, I'd like to express my support
for this suggestion. For my part, I'm mostly interested in the general
development discussion on dpdk-dev, not details about changes in e.g.,
the i40 PMD code. Architecture discussions, usage questions etc tend to
get drowned in an endless flow of patches.

>   - GitHub has a per pull request discussions area, which gives a clean
> way to review all discussions on a specific change.

... and I think this is one of the great features of github. For an
example on how discussions on merge requests can look, take a look at
e.g., one of the rust-lang merge requests:

  https://github.com/rust-lang/rust/pull/25058#discussion_r29548050

which shows nice git commit links, discussions about relevant parts of
the commits, automatic test results etc. Bug reports also get very
nicely integrated into the workflow.


I used to be more of a command-line guy, but I'm starting to see the
benefits of the github way of doing things, and I think it would be a
nice improvement for DPDK to start using it as well.

// Simon

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

[Marc Sune]

On 04/05/15 08:52, Simon Ka*gstro"m wrote:
> On 2015-05-01 17:56, Wiles, Keith wrote:
>> I believe the DPDK community would benefit from moving to GitHub as the
>> primary DPDK site. http://github.com
>> [...]
> While I'm really mostly a DPDK outsider, I'd like to express my support
> for this suggestion. For my part, I'm mostly interested in the general
> development discussion on dpdk-dev, not details about changes in e.g.,
> the i40 PMD code. Architecture discussions, usage questions etc tend to
> get drowned in an endless flow of patches.

Indeed. I was proposing in this mail:

http://dpdk.org/ml/archives/dev/2015-April/016909.html

to have dpdk-users and dpdk-dev.

>>   - GitHub has a per pull request discussions area, which gives a clean
>> way to review all discussions on a specific change.
> ... and I think this is one of the great features of github. For an
> example on how discussions on merge requests can look, take a look at
> e.g., one of the rust-lang merge requests:
>
>   https://github.com/rust-lang/rust/pull/25058#discussion_r29548050
>
> which shows nice git commit links, discussions about relevant parts of
> the commits, automatic test results etc. Bug reports also get very
> nicely integrated into the workflow.
>
>
> I used to be more of a command-line guy, but I'm starting to see the
> benefits of the github way of doing things, and I think it would be a
> nice improvement for DPDK to start using it as well.

I agree that patch/bug discussion gets slightly improved, and scoped
(which is good and bad). I think we need to find a good integration with
the mailing list in order to both coexist.

Discussions cannot be broken into ML and GH.

marc

>
> // Simon

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

[Mcnamara, John]

Hi,

It is always difficult to sell change unless there is a majority
in favour of it. If the project was already on GitHub and someone
was proposing to move to a ML/Patch workflow then we would
probably see as much resistance.

Here are some advantages and disadvantage of GitHub from personal
experience of working with projects that were exclusively hosted
there.

Some advantages of GitHub:

* Integrated bug tracker with #num linking of commits to issues
  and issues to commits.

* Inline code reviews of pull requests (PR)s.

* Patches can be viewed in the context of the surrounding code.

* Ability to tag issues/PRs with tags like "Bug", "Documentation"
  and to add them to milestones. This give a project level view
  of the current state of issues/PRs.

* Easy integration and automatic updating with third party tools
  like ReadTheDocs, TravisCI and Coverity. This makes it very
  easy to setup a continuous integration environment.

Personally, I find the third party tool integration the most
compelling feature. It allows you to configure the tools to work
with updates to the repo rather than configuring the repo (via
hooks) to work with the tools. The issue tracker integration is
also very useful.

These features aren't exclusive to GitHub and we could probably
replicate the useful ones into our current workflow (issue
tracking in particular is missing). The advantage that GitHub has
is that these features are already there and fully integrated.

Some disadvantages of using GitHub:

* Issue/PR discussions aren't threaded and in long discussions it
  can be a little unclear who is replying to whom/what.

* If there are a lot of forks with PRs the network tree becomes
  too big and GitHub doesn't display it.

* The fork/PR workflow with rebasing, squashing and "push
  --force" on branches is probably a significant change to most
  people's workflow.

John.
-- 

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

[Thomas Monjalon]

[-- Attachment #1: Type: text/plain, Size: 4851 bytes --]

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.

Thanks for reading

[-- Attachment #2: web-sessions-per-month.png --]
[-- Type: image/png, Size: 22531 bytes --]

[-- Attachment #3: github-20150506.png --]
[-- Type: image/png, Size: 68220 bytes --]

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

[Marc Sune]

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

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

[Wiles, Keith]

Hi Thomas, (sorry about the length)

On 5/6/15, 2:37 PM, "Marc Sune" <marc.sune@bisdn.de> wrote:

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

The emails above show one thing we can not make a decision on how to
proceed. We have no method to decide on a topic, look at coding style we
have yet to make any head way and it is unclear how we can decide on a
path. We can not vote and we do not have a king of the repo to make those
decisions, it just dies with out being resolved.

I was hoping the moving to Github would allow us to have multiple
persons/companies equal access to the repos/web pages and other functions
on a third party site. With this move we would put processes in place to
start fixing these problems. I know we can do this now, but the move IMO
was how we get it started. We should start now anyway.

We are all over the world and it would be good to have a neutral worldwide
site to give everyone a equal foothold into DPDK. I was hoping it would
reduce some cost and time from 6Wind, but maybe it is consider just the
cost of doing business for 6Wind.

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

The patchwork site would not be required for Github as you can review and
see all of the pull requests. Also the pull requested are quickly accessed
to sort and manage the patches IMO better then patchwork. The feature is
built into GitHub and we do not need to maintain that site or tool. The
pull requests can also be placed into given states just like patchwork.
The patchwork interface is clunky to me as it seems to be odd to manage
patches, maybe they can fix the usability issues. The filter button is not
very visible and when you need to change a set of patches you have to do a
lot of clicks and back pages to change them all. Maybe I do not know how
to use the site, but I do not think that is the problem IMO. The GitHub
one works today without having to fix anything.

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

I like the idea of going to the GitHub page and being able to scroll down
the page to see all of the repos at the same time. This way people notice
the other tools and subtrees quickly. I know you can modify the web page
to make it easier to see, but Github already has it done.

I seem to have to tell people where Pktgen is located on the site just
about every time I talk about it, being on the GitHub list of repos seems
much more obvious to me. I want to make it easy for someone to be added to
the team to help improve the code and a Github team seems like the easiest
way.

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

I agree with Neil on a few more repos for subtrees or submodules, this
allows us in Github to have different teams and members on those repos as
committers. Adding new persons to teams is quick and easy for anyone on
the team to add or modify someone on the team. The owners have full power
for all teams and adding/removing contributors plus creating or deleting
repos and other functions.

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

GitHub or the current system does not address this concern, but I do not
see that Github would restrict anything. I am not saying you made that
point, but pointing out it needs to be address and is not a pro/con.

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

With the github pages we can have anyone modify the pages and does not
have to be you or someone at 6Wind. The Github web page support is already
present and is contained in the repo as a branch for each repo, if we need
it. To me it just seems easier for someone in the ³wed-page" team to
modify quickly.

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

 Has two modes side by side diff or standard inline diff support.

>> - integrated bug tracker

The bug tracker is something we need now that we have more patches and
users.

>> Cons:
>> - full feature usage implies everybody is forced to use it

I use GitHub for Pktgen for a long time and the only time I really needed
to touch the 

>> - fragmentation between online data and mailing list

The fragmentation is something I want to solve as have seen some comments
about integrating the two systems with some open source code, which I
would hope will solve that problem. More investigation needs to be done.

>> - discussions are not threaded, long discussions not clear
>> - editing in browser may be limited

Personally I only used the web based editing of files to update the
version number on the readme when I forgot. I would not suggest you do all
of your coding in the web browser, but on your local repo copy and editor
of choose.

>> - no offline access

You have the local repo as your offline access, is this what you mean? I
site may go down, but I expect it would be the same for any site. If
GitHub is causing the down time this is a different problem IMO.

>> - difficult to follow history as we rely on user repositories which may
>>change

The pull requests have the history just like patches do today, it should
not be any different. How do you think we will lose history?

>> - GitHub (commercial service) is watching us

If you have not figured it out yet, everyone is out to get everyone else
now in this global Internet Fad :-)

>> - how to leave and migrate data from GitHub?

I think that is kind of easy just clone the repo is that not the case? I
can see we would lose some of the comments, but I am not sure they are
that worth wild. Besides we can always keep the site as a mirror if we
decide to move.

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

OK, great you are the one that created that account I created the
https://github.com/dpdk-org one not knowing who created it.

>> My opinion is that GitHub offers some nice tools and toys but some
>>people
>> won't be comfortable with it.

I think the same is for others not being very comfortable with creating
patches and emailing them as well, so this one is tie IMO.

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

The sandbox I created was for that purpose and anyone is welcome to play
with the site, just let me know. https://github.com/dpdk-org

Thomas, just send me a GitHub login name and I can add you as an owner to
the dpdk-org site or anyone else you want to have as an owner. I have been
adding most as contributors.

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

+1, I too believe we can make this stable or use the other open source
Github project maybe the place to start.

https://github.com/google/pull-request-mailer

https://github.com/rust-lang/rust/pull/25058#discussion_r29548050

>
>
>
>Best
>Marc
>
>>
>> Thanks for reading
>

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

[Wiles, Keith]

I did not finish a thought for some reason.

On 5/6/15, 4:49 PM, "Wiles, Keith" <keith.wiles@intel.com> wrote:

>Hi Thomas, (sorry about the length)
>
>On 5/6/15, 2:37 PM, "Marc Sune" <marc.sune@bisdn.de> wrote:
>
>>
>>
>>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.
>
>The emails above show one thing we can not make a decision on how to
>proceed. We have no method to decide on a topic, look at coding style we
>have yet to make any head way and it is unclear how we can decide on a
>path. We can not vote and we do not have a king of the repo to make those
>decisions, it just dies with out being resolved.
>
>I was hoping the moving to Github would allow us to have multiple
>persons/companies equal access to the repos/web pages and other functions
>on a third party site. With this move we would put processes in place to
>start fixing these problems. I know we can do this now, but the move IMO
>was how we get it started. We should start now anyway.
>
>We are all over the world and it would be good to have a neutral worldwide
>site to give everyone a equal foothold into DPDK. I was hoping it would
>reduce some cost and time from 6Wind, but maybe it is consider just the
>cost of doing business for 6Wind.
>
>>> 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
>
>The patchwork site would not be required for Github as you can review and
>see all of the pull requests. Also the pull requested are quickly accessed
>to sort and manage the patches IMO better then patchwork. The feature is
>built into GitHub and we do not need to maintain that site or tool. The
>pull requests can also be placed into given states just like patchwork.
>The patchwork interface is clunky to me as it seems to be odd to manage
>patches, maybe they can fix the usability issues. The filter button is not
>very visible and when you need to change a set of patches you have to do a
>lot of clicks and back pages to change them all. Maybe I do not know how
>to use the site, but I do not think that is the problem IMO. The GitHub
>one works today without having to fix anything.
>
>>>
>>> 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
>
>I like the idea of going to the GitHub page and being able to scroll down
>the page to see all of the repos at the same time. This way people notice
>the other tools and subtrees quickly. I know you can modify the web page
>to make it easier to see, but Github already has it done.
>
>I seem to have to tell people where Pktgen is located on the site just
>about every time I talk about it, being on the GitHub list of repos seems
>much more obvious to me. I want to make it easy for someone to be added to
>the team to help improve the code and a Github team seems like the easiest
>way.
>
>>> 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.
>
>I agree with Neil on a few more repos for subtrees or submodules, this
>allows us in Github to have different teams and members on those repos as
>committers. Adding new persons to teams is quick and easy for anyone on
>the team to add or modify someone on the team. The owners have full power
>for all teams and adding/removing contributors plus creating or deleting
>repos and other functions.
>
>>>
>>> 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.
>
>GitHub or the current system does not address this concern, but I do not
>see that Github would restrict anything. I am not saying you made that
>point, but pointing out it needs to be address and is not a pro/con.
>
>>>
>>> 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
>
>With the github pages we can have anyone modify the pages and does not
>have to be you or someone at 6Wind. The Github web page support is already
>present and is contained in the repo as a branch for each repo, if we need
>it. To me it just seems easier for someone in the ³wed-page" team to
>modify quickly.
>
>>> - 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
>
> Has two modes side by side diff or standard inline diff support.
>
>>> - integrated bug tracker
>
>The bug tracker is something we need now that we have more patches and
>users.
>
>>> Cons:
>>> - full feature usage implies everybody is forced to use it

I use GitHub for Pktgen for a long time and the only time I really needed
to touch the GitHub web page was if I wanted to verify the README or
something was correct after I pushed the commits. Normally I just used
command line pull/commit to update my local repo, do all of my
testing/development then commit and push the changes to the GitHub report.
At this point everyone one that was following would get a notice. To me it
seemed like Github was just a remote repo in my day to day work looks like
what I believe everyone is doing now. Maybe someone can explain what is so
different for the day to day workflow.

> 
>
>>> - fragmentation between online data and mailing list
>
>The fragmentation is something I want to solve as have seen some comments
>about integrating the two systems with some open source code, which I
>would hope will solve that problem. More investigation needs to be done.
>
>>> - discussions are not threaded, long discussions not clear
>>> - editing in browser may be limited
>
>Personally I only used the web based editing of files to update the
>version number on the readme when I forgot. I would not suggest you do all
>of your coding in the web browser, but on your local repo copy and editor
>of choose.
>
>>> - no offline access
>
>You have the local repo as your offline access, is this what you mean? I
>site may go down, but I expect it would be the same for any site. If
>GitHub is causing the down time this is a different problem IMO.
>
>>> - difficult to follow history as we rely on user repositories which may
>>>change
>
>The pull requests have the history just like patches do today, it should
>not be any different. How do you think we will lose history?
>
>>> - GitHub (commercial service) is watching us
>
>If you have not figured it out yet, everyone is out to get everyone else
>now in this global Internet Fad :-)
>
>>> - how to leave and migrate data from GitHub?
>
>I think that is kind of easy just clone the repo is that not the case? I
>can see we would lose some of the comments, but I am not sure they are
>that worth wild. Besides we can always keep the site as a mirror if we
>decide to move.
>
>>> - 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.
>
>OK, great you are the one that created that account I created the
>https://github.com/dpdk-org one not knowing who created it.
>
>>> My opinion is that GitHub offers some nice tools and toys but some
>>>people
>>> won't be comfortable with it.
>
>I think the same is for others not being very comfortable with creating
>patches and emailing them as well, so this one is tie IMO.
>
>>> 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.
>
>The sandbox I created was for that purpose and anyone is welcome to play
>with the site, just let me know. https://github.com/dpdk-org
>
>Thomas, just send me a GitHub login name and I can add you as an owner to
>the dpdk-org site or anyone else you want to have as an owner. I have been
>adding most as contributors.
>
>>
>>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.
>
>+1, I too believe we can make this stable or use the other open source
>Github project maybe the place to start.
>
>https://github.com/google/pull-request-mailer
>
>https://github.com/rust-lang/rust/pull/25058#discussion_r29548050
>
>>
>>
>>
>>Best
>>Marc
>>
>>>
>>> Thanks for reading
>>
>

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

[Thomas Monjalon]

2015-05-07 03:37, Wiles, Keith:
> On 5/6/15, 4:49 PM, "Wiles, Keith" <keith.wiles@intel.com> wrote:
> >On 5/6/15, 2:37 PM, "Marc Sune" <marc.sune@bisdn.de> wrote:
> >>On 06/05/15 23:09, Thomas Monjalon wrote:
> >>> 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.
> >
> >The emails above show one thing we can not make a decision on how to
> >proceed. We have no method to decide on a topic, look at coding style we
> >have yet to make any head way and it is unclear how we can decide on a
> >path. We can not vote and we do not have a king of the repo to make those
> >decisions, it just dies with out being resolved.

No, coding rules and tools can be brought by patches.
The general rule is to find a consensus.

> >I was hoping the moving to Github would allow us to have multiple
> >persons/companies equal access to the repos/web pages and other functions
> >on a third party site. With this move we would put processes in place to
> >start fixing these problems. I know we can do this now, but the move IMO
> >was how we get it started. We should start now anyway.

It's your vision. Saying it again and again won't make it the universal truth.
We have to take care of everybody and choose the tools and workflow which are
the more convenient for most of us.

> >We are all over the world and it would be good to have a neutral worldwide
> >site to give everyone a equal foothold into DPDK. I was hoping it would
> >reduce some cost and time from 6Wind, but maybe it is consider just the
> >cost of doing business for 6Wind.

I don't understand what you're saying.
dpdk.org is neutral and everybody is welcome.
Changing the site owner won't change the need for an admin and some
restricted permissions.

> >>> 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
> >
> >The patchwork site would not be required for Github as you can review and
> >see all of the pull requests. Also the pull requested are quickly accessed
> >to sort and manage the patches IMO better then patchwork. The feature is
> >built into GitHub and we do not need to maintain that site or tool. The
> >pull requests can also be placed into given states just like patchwork.
> >The patchwork interface is clunky to me as it seems to be odd to manage
> >patches, maybe they can fix the usability issues. The filter button is not
> >very visible and when you need to change a set of patches you have to do a
> >lot of clicks and back pages to change them all. Maybe I do not know how
> >to use the site, but I do not think that is the problem IMO. The GitHub
> >one works today without having to fix anything.
> >
> >>> 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
> >
> >I like the idea of going to the GitHub page and being able to scroll down
> >the page to see all of the repos at the same time. This way people notice
> >the other tools and subtrees quickly. I know you can modify the web page
> >to make it easier to see, but Github already has it done.

What is not clear enough in this organization?
	http://dpdk.org/browse/

> >I seem to have to tell people where Pktgen is located on the site just
> >about every time I talk about it, being on the GitHub list of repos seems
> >much more obvious to me. I want to make it easy for someone to be added to
> >the team to help improve the code and a Github team seems like the easiest
> >way.

What is a github team? You talk about contributors as we have in email workflow?

> >>> 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.
> >
> >I agree with Neil on a few more repos for subtrees or submodules, this
> >allows us in Github to have different teams and members on those repos as
> >committers. Adding new persons to teams is quick and easy for anyone on
> >the team to add or modify someone on the team. The owners have full power
> >for all teams and adding/removing contributors plus creating or deleting
> >repos and other functions.
> >
> >>> 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.
> >
> >GitHub or the current system does not address this concern, but I do not
> >see that Github would restrict anything. I am not saying you made that
> >point, but pointing out it needs to be address and is not a pro/con.
> >
> >>> 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
> >
> >With the github pages we can have anyone modify the pages and does not
> >have to be you or someone at 6Wind. The Github web page support is already
> >present and is contained in the repo as a branch for each repo, if we need
> >it. To me it just seems easier for someone in the ³wed-page" team to
> >modify quickly.

We can open the git tree and a mailing list dedicated to the web site.
So anybody will be able to modify it and submit his proposal.

> >>> - 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
> >
> > Has two modes side by side diff or standard inline diff support.
> >
> >>> - integrated bug tracker
> >
> >The bug tracker is something we need now that we have more patches and
> >users.
> >
> >>> Cons:
> >>> - full feature usage implies everybody is forced to use it
> 
> I use GitHub for Pktgen for a long time and the only time I really needed
> to touch the GitHub web page was if I wanted to verify the README or
> something was correct after I pushed the commits. Normally I just used
> command line pull/commit to update my local repo, do all of my
> testing/development then commit and push the changes to the GitHub report.
> At this point everyone one that was following would get a notice. To me it
> seemed like Github was just a remote repo in my day to day work looks like
> what I believe everyone is doing now. Maybe someone can explain what is so
> different for the day to day workflow.

You were advocating for using GitHub not only as a standard git repo, but also
for the review and bugtracker features. Participating in GitHub review and
bugtracking imply to have a GitHub account.

> >>> - fragmentation between online data and mailing list
> >
> >The fragmentation is something I want to solve as have seen some comments
> >about integrating the two systems with some open source code, which I
> >would hope will solve that problem. More investigation needs to be done.

Yes may be checked.

> >>> - discussions are not threaded, long discussions not clear
> >>> - editing in browser may be limited
> >
> >Personally I only used the web based editing of files to update the
> >version number on the readme when I forgot. I would not suggest you do all
> >of your coding in the web browser, but on your local repo copy and editor
> >of choose.

Of course. I was talking about writing comments for reviews or bugs.

> >>> - no offline access
> >
> >You have the local repo as your offline access, is this what you mean? I
> >site may go down, but I expect it would be the same for any site. If
> >GitHub is causing the down time this is a different problem IMO.

No I mean it is not possible to browse reviews and bugs when you are offline.
Some people (including me) are often offline while travelling.

> >>> - difficult to follow history as we rely on user repositories which may
> >>>change
> >
> >The pull requests have the history just like patches do today, it should
> >not be any different. How do you think we will lose history?

We have no control on user repositories. How is it easy to follow a review
where code was changed (and pushed --force) between comments?
Will it be possible to read an old review when the user repository will be
deleted?

> >>> - GitHub (commercial service) is watching us
> >
> >If you have not figured it out yet, everyone is out to get everyone else
> >now in this global Internet Fad :-)
> >
> >>> - how to leave and migrate data from GitHub?
> >
> >I think that is kind of easy just clone the repo is that not the case? I
> >can see we would lose some of the comments, but I am not sure they are
> >that worth wild. Besides we can always keep the site as a mirror if we
> >decide to move.

I'm thinking to metadata (comments, bugs, etc). This history is important to
understand previous choices and avoid repeating same errors.

> >>> - 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.
> >
> >OK, great you are the one that created that account I created the
> >https://github.com/dpdk-org one not knowing who created it.

No, I'm not the owner of this account.
I did an abuse report and I wait for an answer from the unknown owner.

> >>> My opinion is that GitHub offers some nice tools and toys but some
> >>>people
> >>> won't be comfortable with it.
> >
> >I think the same is for others not being very comfortable with creating
> >patches and emailing them as well, so this one is tie IMO.

Yes, we are in a tie. So I don't see how it could be possible to force
people to change.
As explained at the beginning, people from Linux, Qemu, GLIBC, GCC and
comfortable with email workflow deserve as much respect as web lovers.

> >>> 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.
> >
> >The sandbox I created was for that purpose and anyone is welcome to play
> >with the site, just let me know. https://github.com/dpdk-org
> >
> >Thomas, just send me a GitHub login name and I can add you as an owner to
> >the dpdk-org site or anyone else you want to have as an owner. I have been
> >adding most as contributors.
> >
> >>
> >>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.
> >
> >+1, I too believe we can make this stable or use the other open source
> >Github project maybe the place to start.
> >
> >https://github.com/google/pull-request-mailer
> >
> >https://github.com/rust-lang/rust/pull/25058#discussion_r29548050
> >
> >>
> >>
> >>
> >>Best
> >>Marc