Search Linux Wireless

Re: [RFC 0/1] Allow MAC change on up interface

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Johannes,

On 8/20/19 2:32 PM, Johannes Berg wrote:
Hi Denis,

Rather than replying to all the separate items here, just two things:

1) I'll reiterate - please keep things civil. You're taking things out
    of context a *lot* here, in what seems like an attempt to draw a
    parallel between my and your utterances.

2) I'll take your point that I've been somewhat dismissive in tone, and
    will try to change that.


I'll apologize for the methods I used, but you were not getting to 2) above via our earlier discussions. Anyway, peace.


I do want to reply to two things specifically though:

Fine.  I get that.  But how about asking what the use case is? Or say
you don't quite understand why something is needed?

Really, I should *not* have to ask that. You should consider it your
obligation to provide enough information for me to review patches
without having to go back and ask what it is you actually want to
achieve.

So let me ask you this. What do you _want_ to see when a contributor submits something as an RFC, which that contributor states is not ready for 'true' review and is really there to generate feedback?

Do you want to have that contributor use a different prefix? Every maintainer is differrent. I get that. So if we want to start an actual brainstorming session with you, how do we accomplish that?


Compared to some other subsystems and maintainers I've dealt with, I
think I've actually been rather patient in trying to extract the purpose
of your changes, rather than *really* just dismissing them (which I've
felt like many times.)


I'll admit you're not the worst I've dealt with, but you can always improve, right? :)

a maintainer who's job (by definition)
is to encourage new contributors and improve the subsystem he
maintains...?

This is what maybe you see as the maintainer's role, but I disagree, at
least to some extent. I see the role more of a supervisor, somebody
who's ensuring that all the changes coming in will work together. Yes, I
have my own incentive to improve things, but if you have a particular
incentive to improve a particular use case, the onus really is on you to
convince me of that, not on me to try to ferret the reasoning out of you
and make those improvements my own.


So this goes back to my earlier point. How do you want us to start a discussion with you such that you don't become a 'supervisor' and instead try to understand the pain points first?

And really, we are not expecting you to do the improvements on your own. But you know the subsystem best. So you really should consider giving actual guidance on how to accomplish something in the best way.

Also, look at it from the PoV of any new contributor. So while I can definitely relate to what you're saying here, I think you should put yourself in your peer's shoes and try to be more understanding of their perspective. At least make the effort to hear people out...


So please - come with some actual reasoning. This particular thread only
offered "would elminate a few potential race conditions", in the cover
letter, not even the patch itself, so it wasn't very useful. I was
perhaps less than courteous trying to extract the reasoning, but I
shouldn't have to in the first place.


Okay, so we'll work on that. But this is a two way street too. And sometimes it seems like you're not actually reading the cover letters ;)

Regards,
-Denis



[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux