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

[Neil Horman <nhorman@tuxdriver.com>]

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