[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 at 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 at 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 at intel.com> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>>> On 5/4/15, 10:48 AM, "Matthew Hall" <mhall at 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
>