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

["Wiles, Keith" <keith.wiles@intel.com>]

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



>