[lkml]   [2018]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
On Tue, Oct 23 2018, Al Viro wrote:

> On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
>> Currently if a maintainer is rude to you, there is no where else that
>> you can go and *that* is why it hurts. It isn't the abuse so much as
>> the powerlessness associated with it. If you can (metaphorically) say
>> to that maintainer "I don't care about your toilet mouth, you've just
>> given me the right to take my petition to caesar" - then the emotional
>> response will be quite different to pain.
> Bollocks. First of all, you *always* can take patches to Linus, even if
> maintainer is being the sodding Miss Manners. Always could. What you
> can't (and shouldn't be able to) is to _force_ a piece of shit patch
> (pardon the toilet mouth) into the tree on the grounds of maintainer having
> been "rude" to your patch.

Yes, you could, and you can. But if it was Linus who was behaving
inappropriately, where did you go then? This is why I think whatever
"code" we have should be overtly a statement Linus makes about his
behaviour, in the first instance.

And of course a bad patch should be rejected. In many cases a bad patch
can then be improved. If the maintainer responds badly to your first (bad)
patch, it can be very hard to try again - once bitten twice shy, as they

The point of being able to circumvent a maintainer is to be able to get
relevant rational review, instead of emotional attacks.

> Again, you can and always could appeal to Linus if your patches are wrongly
> rejected, in your opinion. You'd better have good evidence supporting the
> "wrongly" bit in that case, but the "right to petition" model implies that
> anyway.

I wonder how many people know about this right-to-petition, or use it.
Maybe it should be stated in the "Code of conduct".

> If you are talking about the situations when "rude" maintainer makes insufferable
> requests to one's precious patches (e.g. demonstrates his or her mental inferiority
> by admitting that they are unable to follow contributor's 0.5KLoC of spaghetty in a
> single function and has an unspeakable gall to demand to clean it up - instead of
> passing that task upon the interns, as they ought to[1])... sure, that would be
> something new. Would you care to be the person charged with dealing with such...
> valuable contributors? And how good is the coverage of psychiatric treatments
> offered by your medical insurance?
> [1] no, I'm not making it up
>> If Linus is not true to his new-found sensitivity, we might need someone
>> (Greg?) to be a co-maintainer, able to accept patches when Linus has a
>> relapse. It might be good form to create this channel anyway, but I
>> doubt it would be needed in practice.
>> So there you have it. The "Code" is upside down.
>> We need documents which:
>> - curtail the power of the strong, starting with Linus
>> - are adopted willingly by individuals, not imposed on the community.
>> - provide alternate routes for patch-flow, so that no-one has ultimate
>> power.
> Really? The ultimate power being to say "No" to a patch, and nobody should
> have such? Are you fucking serious?

I have noticed of late a tendency in all sorts of different people to
hear/read a statement from someone they know, interpret it a particular
way, be surprised about that interpretation, and persist with believing
that interpretation anyway, rather than realizing that the most likely
explanation is a communication failure, and asking for clarification.

The "ultimate power" is the ability to say "no" to a patch, *with no
opportunity for review*. Two people together having that ultimate power
is a totally different thing to one person having it alone.

[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2018-10-23 06:26    [W:0.169 / U:12.352 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site