From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 4E90BC5CA for ; Mon, 4 May 2015 05:51:26 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga101.fm.intel.com with ESMTP; 03 May 2015 20:51:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,363,1427785200"; d="scan'208";a="565702458" Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by orsmga003.jf.intel.com with ESMTP; 03 May 2015 20:51:25 -0700 Received: from fmsmsx103.amr.corp.intel.com (10.18.124.201) by ORSMSX107.amr.corp.intel.com (10.22.240.5) with Microsoft SMTP Server (TLS) id 14.3.224.2; Sun, 3 May 2015 20:51:25 -0700 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.26]) by FMSMSX103.amr.corp.intel.com ([169.254.2.177]) with mapi id 14.03.0224.002; Sun, 3 May 2015 20:51:24 -0700 From: "Wiles, Keith" To: Neil Horman Thread-Topic: [dpdk-dev] GitHub sandbox for the DPDK community Thread-Index: AQHQhCdlg1RCyqklQ0KpSAVz9bdNYJ1nyWwAgAAM1QCAABWJgP//slCAgAOXQ4D///1+gA== Date: Mon, 4 May 2015 03:51:23 +0000 Message-ID: References: <20150501164512.GB27756@hmsreliant.think-freely.org> <20150501173108.GA24714@mhcomputing.net> <20150501184813.GC27756@hmsreliant.think-freely.org> <20150503210018.GA8090@neilslaptop.think-freely.org> In-Reply-To: <20150503210018.GA8090@neilslaptop.think-freely.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.190.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <046D81088573254280001CC1430CBFAB@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] GitHub sandbox for the DPDK community X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 03:51:27 -0000 Neil On 5/3/15, 2:00 PM, "Neil Horman" wrote: >On Fri, May 01, 2015 at 07:10:11PM +0000, Wiles, Keith wrote: >>=20 >>=20 >> On 5/1/15, 1:48 PM, "Neil Horman" wrote: >>=20 >> >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. >> >>=20 >> >> Normally I'm a big command-line supporter. However I have found >> >>reviewing=20 >> >> patches by email for me is about the most painful workflow. >> >>=20 >> >> The emails are pages and pages. >> >>=20 >> >So collapse the quoted text (see below) >> > >> >> The replies from commenters are buried in the walls of text. >> >>=20 >> >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=20 >> >> gets weirder and weirder to try to read. >> >>=20 >> >Text Collapse will reformat that for you. >> > >> >> Quickly reading over the patchset by scrolling through to get the >> >>flavor of=20 >> >> it, to see if I'm qualified to review it, and look at the parts I >> >>actually=20 >> >> know about is much harder. >> >>=20 >> >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=20 >> >> Request page. Then I can just sync up the branch and test it on my >>own >> >>systems=20 >> >> to see if it works, not just try to read it. >> >>=20 >> >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=20 >> >> 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. >>=20 >> 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) :-) >>=20 >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.=20 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. >>=20 >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. >>=20 >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 > >> > >> >>=20 >> >> All in all, I'd be able to review more DPDK patches faster with the >>GH >> >> interface than having them in the mailing list. >> >>=20 >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 >