linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Williams <dcbw@redhat.com>
To: Denis Kenzior <denkenz@gmail.com>,
	Johannes Berg <johannes@sipsolutions.net>,
	James Prestwood <prestwoj@gmail.com>,
	linux-wireless@vger.kernel.org
Subject: Re: [RFC 0/1] Allow MAC change on up interface
Date: Tue, 20 Aug 2019 12:53:44 -0500	[thread overview]
Message-ID: <32547793981b3997f7e0f74137745f38615e5c54.camel@redhat.com> (raw)
In-Reply-To: <7b9a7df3-6880-98f6-5c09-257165025559@gmail.com>

On Tue, 2019-08-20 at 10:40 -0500, Denis Kenzior wrote:
> Hi Johannes,
> 
> > Stop.
> > 
> > Your tone, and in particular the constant snide comments and
> > attacks on
> > me are, quite frankly, getting extremely tiring.
> > 
> 
> Look, I'm sorry I hit a nerve, but from where I am sitting, it had to
> be 
> said...

But did it really? And in that way?  There were certainly better ways
to go about that response.

I don't recall seeing a NAK anywhere his email chain (which you'd get
with some other kernel maintainers) but instead (a) an explanation of
why the proposed solution had some problems, (b) some alternative
possibilities and (c) requests for more information so the discussion
could continue.

It does the requested changes no good to take that kind of tone. Let's
move on from here and keep things constructive to solve the problem at
hand, which is:

"Changing the MAC address of a WiFi interface takes longer than I'd
like and clears some state that I'd like it to keep."

That is a technical problem we can solve, so let's keep it at that
level.

Dan

> Regardless.  Peace, I'm not trying to start drama here.  We just want
> to 
> improve things and it feels like you're shutting down every idea
> without 
> truly understanding the issues we're facing.
> 
> > It almost seems like you're just trying to bully me into taking
> > your
> > patches by constantly trying to make me feel that I cannot know
> > better
> > anyway. This is not how you should be treating anyone.
> > 
> 
> Before lecturing me on my tone, can you go back and re-read your 
> responses to many of the contributors here?  I mean really read
> them? 
> Your tone is quite dismissive, whether intentional or not.  When one
> of 
> my guys comes to me and says:
> 	"Johannes' response was completely useless, it feels like he
> didn't 
> even read my cover letter"
> 
> I will come out and call you on it.  So if you don't mean to come
> off 
> that way, great.  We'll just chalk it up to a mis-understanding.
> 
> > Look, I did say I don't see a point in this, but you're taking that
> > out
> > of context. I also stated that I didn't understand the whole thing
> > about
> > "race conditions" and all, because nobody actually explained the
> > reasoning behind the changes here.
> 
> Fine.  I get that.  But how about asking what the use case is? Or
> say 
> you don't quite understand why something is needed?  We'll happily 
> explain.  When the first reaction to an RFC is: "I don't see the
> point" 
> or "You're doing it wrong" from a maintainer who's job (by
> definition) 
> is to encourage new contributors and improve the subsystem he 
> maintains...?  Well that's kind of a downer, don't you
> agree?  You're 
> the maintainer and you should be held to a higher standard...
> 
> I maintain 3 projects, I know the job isn't great, but you still
> should 
> be (more) civil to people...
> 
> > James, unlike you, managed to reply on point and explain why it was
> > needed. If all you can do is accuse me of not using the software
> > and
> > therefore not knowing how it should be used, even implying that I'm
> > not
> > smart enough to understand the use cases, then I don't know why you
> > bother replying at all.
> 
> Good on James.  I council all my guys to keep cool when dealing with 
> upstream.  But that doesn't mean you should be dismissing things out
> of 
> hand on the very first interaction you have with a new contributor.
> 
> > I can understand your frustration to some extent, and I want to
> > give you
> > the benefit of doubt and want to believe this behaviour was borne
> > out of
> > it, since I've been reviewing your changes relatively critically.
> > 
> 
> Good.  I want you to do that.  The changes are in very tricky areas
> and 
> you know the code best.
> 
> > However, I also want to believe that I've been (trying to) keep the
> > discussion on a technical level, telling you why I believe some
> > things
> > shouldn't be done the way you did them, rather than telling you
> > that
> > you're not smart enough to be working on this. If you feel
> > otherwise,
> > please do let me know and I'll go back to understand, in order to
> > improve my behaviour in the future.
> 
> If you interpreted my rants as an assault to your intelligence, then
> I'm 
> sorry.  They really were not meant this way.  But sometimes we
> really 
> had to wonder if you were using the same API we were?  So the
> question I 
> asked above was purely logical consequence of what I was seeing.
> 
> You yourself admitted that you have never implemented an event
> driven 
> stack.  So how about listening to the guys that are?
> 
> We are using your APIs in different ways.  So instead of questioning
> why 
> or attacking those ways, how about asking whether improvements can be
> made?
> 
> We are facing serious pain points with the API.  So instead of 
> dismissing things out of hand, can we work together to improve
> things?
> 
> We are trying to make things fast.  The API is frequently not setup
> for 
> that.  The MAC randomization is just one example.  Bringing down the 
> interface (and shutting down the firmware, toggling power state, 
> cleaning up resources/state) prior to every connection is just not 
> acceptable.  Look at the link I sent.  The Android guys state 3
> seconds 
> is the typical 'hit'.  This is literally wasting everyone's time.
> 
> > Please help keep the discussion technical, without demeaning
> > undertones.
> 
> Point taken.  And I apologize again.  But please consider what I said
> above.
> 
> Regards,
> -Denis


  reply	other threads:[~2019-08-20 17:53 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-15 18:57 [RFC 0/1] Allow MAC change on up interface James Prestwood
2019-08-15 18:57 ` [RFC 1/1] RFC: allow mac address change on up iface James Prestwood
2019-08-15 20:48 ` [RFC 0/1] Allow MAC change on up interface Jeff Johnson
2019-08-16  9:56   ` Toke Høiland-Jørgensen
2019-08-19 10:14 ` Johannes Berg
2019-08-19 15:55   ` James Prestwood
2019-08-19 20:20     ` Johannes Berg
2019-08-19 20:58       ` Denis Kenzior
2019-08-20  8:59         ` Johannes Berg
2019-08-20 15:40           ` Denis Kenzior
2019-08-20 17:53             ` Dan Williams [this message]
2019-08-20 18:21               ` Denis Kenzior
2019-08-20 18:54                 ` Toke Høiland-Jørgensen
2019-08-20 19:32             ` Johannes Berg
2019-08-20 19:46               ` Denis Kenzior
2019-08-20 20:01                 ` Johannes Berg
2019-08-19 21:14       ` James Prestwood
2019-08-20  6:59         ` Johannes Berg
2019-08-20 19:22           ` Denis Kenzior
2019-08-20 19:43             ` Johannes Berg
2019-08-20 19:58               ` Denis Kenzior
2019-08-20 20:15                 ` Johannes Berg
2019-08-20 20:37                   ` Denis Kenzior
2019-08-20 21:18                     ` Dan Williams
2019-08-20 21:52                       ` Denis Kenzior
2019-08-21  7:21                         ` Johannes Berg
2019-08-20 19:53           ` James Prestwood
2019-08-20 20:06             ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=32547793981b3997f7e0f74137745f38615e5c54.camel@redhat.com \
    --to=dcbw@redhat.com \
    --cc=denkenz@gmail.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=prestwoj@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).