Re: [ 00/19] 3.10.1-stable review

Re: [ 00/19] 3.10.1-stable review

[Sarah Sharp]

On Fri, 12 Jul 2013 18:17:08 +0200, Ingo Molnar <mingo@kernel.org> wrote:
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > On Fri, Jul 12, 2013 at 8:47 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > >
> > > I tend to hold things off after -rc4 because you scare me more than Greg
> > > does ;-)
> > 
> > Have you guys *seen* Greg? The guy is a freakish giant. He *should*
> > scare you. He might squish you without ever even noticing.
> 
> Greg might be a giant and he might squish people without ever even 
> noticing, but that's just a grave, deadly physical threat no real kernel 
> hacker ever feels threatened by. (Not much can hurt us deep in our dark 
> basements after all, except maybe earthquakes, gamma ray eruptions and Mom 
> trying to clean up around the computers.)
> 
> So Greg, if you want it all to change, create some _real_ threat: be frank 
> with contributors and sometimes swear a bit. That will cut your mailqueue 
> in half, promise!

On Fri, 12 Jul 2013 08:22:27 -0700, Linus wrote:
> Greg, the reason you get a lot of stable patches seems to be that you
> make it easy to act as a door-mat. Clearly at least some people say "I
> know this patch isn't important enough to send to Linus, but I know Greg
> will silently accept it after the fact, so I'll just wait and mark it
> for stable".
>
> You may need to learn to shout at people.

Seriously, guys?  Is this what we need in order to get improve -stable?
Linus Torvalds is advocating for physical intimidation and violence.
Ingo Molnar and Linus are advocating for verbal abuse.

Not *fucking* cool.  Violence, whether it be physical intimidation,
verbal threats or verbal abuse is not acceptable.  Keep it professional
on the mailing lists.

Let's discuss this at Kernel Summit where we can at least yell at each
other in person.  Yeah, just try yelling at me about this.  I'll roar
right back, louder, for all the people who lose their voice when they
get yelled at by top maintainers.  I won't be the nice girl anymore.

Sarah Sharp

Re: [ 00/19] 3.10.1-stable review

[Linus Torvalds]

On Mon, Jul 15, 2013 at 8:52 AM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
>
>                                                             I'll roar
> right back, louder, for all the people who lose their voice when they
> get yelled at by top maintainers.  I won't be the nice girl anymore.

That's the spirit.

Greg has taught you well. You have controlled your fear. Now, release
your anger. Only your hatred can destroy me.

Come to the dark side, Sarah. We have cookies.

                   Linus

Re: [ 00/19] 3.10.1-stable review

[Darren Hart]

On Mon, 2013-07-15 at 08:52 -0700, Sarah Sharp wrote:
> On Fri, 12 Jul 2013 18:17:08 +0200, Ingo Molnar <mingo@kernel.org> wrote:
> > * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > 
> > > On Fri, Jul 12, 2013 at 8:47 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > > >
> > > > I tend to hold things off after -rc4 because you scare me more than Greg
> > > > does ;-)
> > > 
> > > Have you guys *seen* Greg? The guy is a freakish giant. He *should*
> > > scare you. He might squish you without ever even noticing.
> > 
> > Greg might be a giant and he might squish people without ever even 
> > noticing, but that's just a grave, deadly physical threat no real kernel 
> > hacker ever feels threatened by. (Not much can hurt us deep in our dark 
> > basements after all, except maybe earthquakes, gamma ray eruptions and Mom 
> > trying to clean up around the computers.)
> > 
> > So Greg, if you want it all to change, create some _real_ threat: be frank 
> > with contributors and sometimes swear a bit. That will cut your mailqueue 
> > in half, promise!
> 
> On Fri, 12 Jul 2013 08:22:27 -0700, Linus wrote:
> > Greg, the reason you get a lot of stable patches seems to be that you
> > make it easy to act as a door-mat. Clearly at least some people say "I
> > know this patch isn't important enough to send to Linus, but I know Greg
> > will silently accept it after the fact, so I'll just wait and mark it
> > for stable".
> >
> > You may need to learn to shout at people.
> 
> Seriously, guys?  Is this what we need in order to get improve -stable?
> Linus Torvalds is advocating for physical intimidation and violence.
> Ingo Molnar and Linus are advocating for verbal abuse.
> 
> Not *fucking* cool.  Violence, whether it be physical intimidation,
> verbal threats or verbal abuse is not acceptable.  Keep it professional
> on the mailing lists.
>
> Let's discuss this at Kernel Summit where we can at least yell at each
> other in person.  Yeah, just try yelling at me about this.  I'll roar
> right back, louder, for all the people who lose their voice when they
> get yelled at by top maintainers.  I won't be the nice girl anymore.
> 
> Sarah Sharp


Having sent Greg an inappropriate device support patch (for stable)
right smack dab in the middle of this thread, what I can say as a
developer who tends to have to work all over the place in the kernel,
is that deriving the rules is still difficult (as Guenter Roeck has
alluded to in his posts here).

Greg's response to me was direct, informative, and maybe just a little
bit shame-inducing "You know better than that." I know Greg well enough
not to take that personally and I can see him saying that with a smile
on his face, so no complaints there. However, the truth is, I didn't
know better because despite having read the docs, it wasn't clear to
me. Part of the reason there is the language used wasn't clear to me,
specifically "New device IDs and quirks are also accepted". I took
quirks to mean augmenting existing drivers to handle new devices with
subtle changes when in fact it meant something more along the lines of
a couple of lines to add device IDs and existing quirks to a new
device. Greg provided me with example commit IDs which met that
requirement (and perhaps such examples should be added to the docs).

I believe we could improve that documentation to help clarify the
requirements to people that don't work with it everyday. I have offered
to have a look and see what would have made it more clear to me, and I
will do that.

I do believe our processes are becoming a bit fragmented. While every
maintainer certainly needs some autonomy to be able to define how
people work with them in order to maximize their efficiency, the
difference (or lack thereof) between -RC4 and stable wasn't clear to
me, and couldn't be deduced from stable_kernel_rules. Guenter mentioned
some tribal-knowledge associated with /net rules (which I had just
unwittingly violated in the patch mentioned above). I wonder if we
could somehow merge policies where possible, and document those that
should be different in a place where people are likely to find them -
perhaps associated with get_maintainer.pl since anyone submitting
patches should be checking that output anyway.

In summary, better consolidated documentation using language that is
clear to non-subsystem-experts and less tribal knowledge. If people
don't read the documentation that we put in front of their nose....
well, then I suppose we can scold them a bit.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: [ 00/19] 3.10.1-stable review

[Sarah Sharp]

On Mon, Jul 15, 2013 at 10:08:13AM -0700, Linus Torvalds wrote:
> On Mon, Jul 15, 2013 at 8:52 AM, Sarah Sharp
> <sarah.a.sharp@linux.intel.com> wrote:
> >
> >                                                             I'll roar
> > right back, louder, for all the people who lose their voice when they
> > get yelled at by top maintainers.  I won't be the nice girl anymore.
> 
> That's the spirit.
> 
> Greg has taught you well. You have controlled your fear. Now, release
> your anger. Only your hatred can destroy me.
> 
> Come to the dark side, Sarah. We have cookies.

But, but, the light side has brownies.  Pot brownies that will make
everyone feel sleepy and peaceful and possibly hungry.  For more pot
brownies...

Sarah Sharp

Re: [ 00/19] 3.10.1-stable review

[Linus Torvalds]

On Mon, Jul 15, 2013 at 10:46 AM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
>
> But, but, the light side has brownies.  Pot brownies that will make
> everyone feel sleepy and peaceful and possibly hungry.  For more pot
> brownies...

Hmm. Maybe we should have a BoF at the KS.

I'll bring the regular cookies.

               Linus

Re: [ 00/19] 3.10.1-stable review

[Sarah Sharp]

On Mon, Jul 15, 2013 at 10:50:52AM -0700, Linus Torvalds wrote:
> On Mon, Jul 15, 2013 at 10:46 AM, Sarah Sharp
> <sarah.a.sharp@linux.intel.com> wrote:
> >
> > But, but, the light side has brownies.  Pot brownies that will make
> > everyone feel sleepy and peaceful and possibly hungry.  For more pot
> > brownies...
> 
> Hmm. Maybe we should have a BoF at the KS.
> 
> I'll bring the regular cookies.

Well, we're not in the Netherlands, so I don't think pot brownies could
be smuggled into KS. ;)

However, I am serious about this.  Linus, you're one of the worst
offenders when it comes to verbally abusing people and publicly tearing
their emotions apart.

http://marc.info/?l=linux-kernel&m=135628421403144&w=2
http://marc.info/?l=linux-acpi&m=136157944603147&w=2

I'm not going to put up with that shit any more.

Sarah Sharp

Re: [ 00/19] 3.10.1-stable review

[Linus Torvalds]

On Mon, Jul 15, 2013 at 11:04 AM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
>
> However, I am serious about this.  Linus, you're one of the worst
> offenders when it comes to verbally abusing people and publicly tearing
> their emotions apart.

Yes. And I do it partly (mostly) because it's who I am, and partly
because I honestly despise being subtle or "nice".

The fact is, people need to know what my position on things are. And I
can't just say "please don't do that", because people won't listen. I
say "On the internet, nobody can hear you being subtle", and I mean
it.

And I definitely am not willing to string people along, either. I've
had that happen too - not telling people clearly enough that I don't
like their approach, they go on to re-architect something, and get
really upset when I am then not willing to take their work.

Sarah, first off, I don't have that many tools at hand. Secondly, I
simply don't believe in being polite or politically correct. And you
can point at all those cultural factors where some cultures are not
happy with confrontation (and feel free to make it about gender too -
I think that's almost entirely cultural too). And please bring up
"cultural sensitivity" while at it. And I'll give you back that same
"cultural sensitivity". Please be sensitive to _my_ culture too.

Google "management by perkele".

Do you really want to oppress a minority? Because Finns are a minority
compared to almost any other country. If you want to talk cultural
sensitivity, I'll join you. But my culture includes cursing.

And some of the above is written tonge-in-cheek, but all of it is also
serious. I really fundamentally believe that being honest and open
about your emotions about core/process is good. And because it's damn
hard to read people over email, I think you need to be *more* honest
and *more* open over email. I'm generally nicer in person. Not always.

And yes, I'll happily be part of the discussion at the KS. But I think
you also need to be aware that your "high horse" isn't necessarily all
that high.

              Linus

Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Mon, 2013-07-15 at 10:08 -0700, Linus Torvalds wrote:

> Greg has taught you well. You have controlled your fear. Now, release
> your anger. Only your hatred can destroy me.
> 
> Come to the dark side, Sarah. We have cookies.

http://rostedt.homelinux.com/private/darth-cookie.png

-- Steve

Re: [ 00/19] 3.10.1-stable review

[Sarah Sharp]

On Mon, Jul 15, 2013 at 11:17:06AM -0700, Linus Torvalds wrote:
> On Mon, Jul 15, 2013 at 11:04 AM, Sarah Sharp
> <sarah.a.sharp@linux.intel.com> wrote:
> >
> > However, I am serious about this.  Linus, you're one of the worst
> > offenders when it comes to verbally abusing people and publicly tearing
> > their emotions apart.
> 
> Yes. And I do it partly (mostly) because it's who I am, and partly
> because I honestly despise being subtle or "nice".
> 
> The fact is, people need to know what my position on things are. And I
> can't just say "please don't do that", because people won't listen. I
> say "On the internet, nobody can hear you being subtle", and I mean
> it.
> 
> And I definitely am not willing to string people along, either. I've
> had that happen too - not telling people clearly enough that I don't
> like their approach, they go on to re-architect something, and get
> really upset when I am then not willing to take their work.

You can tell developers in no uncertain terms that you're not willing to
take their work *without* verbally tearing them apart.  You're Linus
Torvalds, for crying out loud!  I simple, "No, that's a bad idea, stop
working on this RIGHT now," is more than enough from you.  If it's not,
well, those people are just dense and can probably put up with stronger
language.

> Sarah, first off, I don't have that many tools at hand. Secondly, I
> simply don't believe in being polite or politically correct.

Bullshit.  I've seen you be polite, and explain to clueless maintainers
why there's no way you can revert their merge that caused regressions,
and ask them to fit it without resorting to tearing them down
emotionally:

http://marc.info/?l=linux-kernel&m=136130347127908&w=2

You just don't want to take the time to be polite to everyone.  Don't
give me the "I'm not polite" card.  Go write some documentation about
what's acceptable for stable.  While you're at it, write some more
documentation about why it's impossible for you to revert merges, so
maintainers know not to send you crap, or piss away time trying to argue
with you that they don't need to fix regressions.  When maintainers
challenge you, point them to it, and say, "Fix this now."

If they protest, then you can bring out the big threats and say, "If you
don't fix this, I won't pull from you the next merge window.  Go find a
backup maintainer that can handle your tree, and train them for the next
release.  You may need to hand over your maintainership to them."

If the maintainer doesn't have sub-maintainers that could take over,
that's a problem we need to fix *before* things like this happen.  We
should discuss which kernel subsystems don't have backups at KS.

There are other tools at hand.  You just don't use them.

> And you can point at all those cultural factors where some cultures
> are not happy with confrontation (and feel free to make it about
> gender too - I think that's almost entirely cultural too). And please
> bring up "cultural sensitivity" while at it. And I'll give you back
> that same "cultural sensitivity". Please be sensitive to _my_ culture
> too.
> 
> Google "management by perkele".
> 
> Do you really want to oppress a minority? Because Finns are a minority
> compared to almost any other country. If you want to talk cultural
> sensitivity, I'll join you. But my culture includes cursing.

Did I mention minorities here at all?  Nope.  My only comment was that I
wasn't going to be a "nice girl" anymore, which is a comment about my
personality, not about the discussion at hand.

*No one* deserves to be yelled at IN ALL CAPS in email, or publicly
ridiculed.  It doesn't matter if they are a minority or not.

You are in a position of power.  Stop verbally abusing your developers.

> And some of the above is written tonge-in-cheek, but all of it is also
> serious. I really fundamentally believe that being honest and open
> about your emotions about core/process is good. And because it's damn
> hard to read people over email, I think you need to be *more* honest
> and *more* open over email. I'm generally nicer in person. Not always.

*Snort*.  Perhaps we haven't interacted very often, but I have never
seen you be nice in person at KS.  Well, there was that one time you
came to me and very quietly explained you had a problem with your USB
3.0 ports, but you came off as "scared to talk to a girl kernel
developer" more than "I'm trying to be polite".

> And yes, I'll happily be part of the discussion at the KS. But I think
> you also need to be aware that your "high horse" isn't necessarily all
> that high.

Dude, I'm not on a horse here.  I'm not asking you to change your
communication styles in order to help minorities.  I'm not some crazy
feminist ranting about cooties on Google+.

I'm trying to improve the kernel mailing lists for all developers.  We
can give negative technical feedback without verbal abuse.

Sarah Sharp

Re: [ 00/19] 3.10.1-stable review

[Rob Landley]

On 07/15/2013 10:52:48 AM, Sarah Sharp wrote:
> On Fri, 12 Jul 2013 18:17:08 +0200, Ingo Molnar <mingo@kernel.org>  
> wrote:
> > * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> Let's discuss this at Kernel Summit where we can at least yell at each
> other in person.  Yeah, just try yelling at me about this.  I'll roar
> right back, louder, for all the people who lose their voice when they
> get yelled at by top maintainers.  I won't be the nice girl anymore.

Not _all_ of us lose our voice when yelled at by Linus's lieutenants.  
Some of us just post updates to the same darn patch series for 5 years  
(yes really; my perl removal series started in 2008 and was applied  
earlier this year), on the theory it's useful to the people actually  
applying it to their own trees (at one point, gentoo), and that someday  
the stars might be right and cthulu will arise from the deep and accept  
the patch series into his tree. (Or in my case, Andrew Morton.)

Hoping initmpfs has an easier time of it, it's already being used in  
supercomputers.

Rob

Re: [ 00/19] 3.10.1-stable review

[J. Bruce Fields]

On Mon, Jul 15, 2013 at 11:17:06AM -0700, Linus Torvalds wrote:
> On Mon, Jul 15, 2013 at 11:04 AM, Sarah Sharp
> <sarah.a.sharp@linux.intel.com> wrote:
> >
> > However, I am serious about this.  Linus, you're one of the worst
> > offenders when it comes to verbally abusing people and publicly tearing
> > their emotions apart.
> 
> Yes. And I do it partly (mostly) because it's who I am, and partly
> because I honestly despise being subtle or "nice".

"Nice", "subtle", and "polite" all seem mostly orthogonal to me.

> The fact is, people need to know what my position on things are. And I
> can't just say "please don't do that", because people won't listen. I
> say "On the internet, nobody can hear you being subtle", and I mean
> it.

And "please don't do that" isn't very subtle.

--b.

> 
> And I definitely am not willing to string people along, either. I've
> had that happen too - not telling people clearly enough that I don't
> like their approach, they go on to re-architect something, and get
> really upset when I am then not willing to take their work.
> 
> Sarah, first off, I don't have that many tools at hand. Secondly, I
> simply don't believe in being polite or politically correct. And you
> can point at all those cultural factors where some cultures are not
> happy with confrontation (and feel free to make it about gender too -
> I think that's almost entirely cultural too). And please bring up
> "cultural sensitivity" while at it. And I'll give you back that same
> "cultural sensitivity". Please be sensitive to _my_ culture too.
> 
> Google "management by perkele".
> 
> Do you really want to oppress a minority? Because Finns are a minority
> compared to almost any other country. If you want to talk cultural
> sensitivity, I'll join you. But my culture includes cursing.
> 
> And some of the above is written tonge-in-cheek, but all of it is also
> serious. I really fundamentally believe that being honest and open
> about your emotions about core/process is good. And because it's damn
> hard to read people over email, I think you need to be *more* honest
> and *more* open over email. I'm generally nicer in person. Not always.
> 
> And yes, I'll happily be part of the discussion at the KS. But I think
> you also need to be aware that your "high horse" isn't necessarily all
> that high.
> 
>               Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Mon, 2013-07-15 at 11:46 -0700, Sarah Sharp wrote:

> *Snort*.  Perhaps we haven't interacted very often, but I have never
> seen you be nice in person at KS.  Well, there was that one time you
> came to me and very quietly explained you had a problem with your USB
> 3.0 ports, but you came off as "scared to talk to a girl kernel
> developer" more than "I'm trying to be polite".
> 

After this email thread, I think I just added you as one of the kernel
developers that scare me ;-)

-- Steve

Re: [ 00/19] 3.10.1-stable review

[Linus Torvalds]

On Mon, Jul 15, 2013 at 11:46 AM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
>
> Bullshit.  I've seen you be polite, and explain to clueless maintainers
> why there's no way you can revert their merge that caused regressions,
> and ask them to fit it without resorting to tearing them down
> emotionally:

Oh, I'll be polite when it's called for.

But when people who know better send me crap, I'll curse at them.

I suspect you'll notice me cursing *way* more at top developers than
random people on the list. I expect more from them, and conversely
I'll be a lot more upset when they do something that I really think
was not great.

For example, my latest cursing explosion was for the x86 maintainers,
and it comes from the fact that I *know* they know to do better. The
x86 tip pulls have generally been through way more testing than most
other pulls I get (not just compiling, but even booting randconfigs
etc). So when an x86 pull request comes in that clearly missed that
expected level of quality, I go to town.

Similarly, you will see fireworks if some long-term maintainer makes
excuses for breaking user space etc. That will make me go into
incoherent rages.

The "polite Linus" example that you point to? That was a maintainer
asking for direction for when things went wrong and *before* sending
me something dubious. Of course I'm polite then.

Sarah, I don't have Tourettes syndrome. You seem to think that my
cursing is uncontrolled and random. I argue that it has causes. Big
difference.

            Linus

Re: [ 00/19] 3.10.1-stable review

[Willy Tarreau]

Hello Sarah,

On Mon, Jul 15, 2013 at 11:46:42AM -0700, Sarah Sharp wrote:
> On Mon, Jul 15, 2013 at 11:17:06AM -0700, Linus Torvalds wrote:
> > On Mon, Jul 15, 2013 at 11:04 AM, Sarah Sharp
> > <sarah.a.sharp@linux.intel.com> wrote:
> > >
> > > However, I am serious about this.  Linus, you're one of the worst
> > > offenders when it comes to verbally abusing people and publicly tearing
> > > their emotions apart.
> > 
> > Yes. And I do it partly (mostly) because it's who I am, and partly
> > because I honestly despise being subtle or "nice".
> > 
> > The fact is, people need to know what my position on things are. And I
> > can't just say "please don't do that", because people won't listen. I
> > say "On the internet, nobody can hear you being subtle", and I mean
> > it.
> > 
> > And I definitely am not willing to string people along, either. I've
> > had that happen too - not telling people clearly enough that I don't
> > like their approach, they go on to re-architect something, and get
> > really upset when I am then not willing to take their work.
> 
> You can tell developers in no uncertain terms that you're not willing to
> take their work *without* verbally tearing them apart.  You're Linus
> Torvalds, for crying out loud!  I simple, "No, that's a bad idea, stop
> working on this RIGHT now," is more than enough from you.  If it's not,
> well, those people are just dense and can probably put up with stronger
> language.

Communication works two ways. You feel emotions based on your references
and on the references you're used from the other person. Most of us have
already been scolded by Linus, and while it usually is an unpleasant moment,
I do think that it's efficient and (it might surprise you) probably a mark
of respect. Please re-read some of the famous public flames from Linus.
When he tells you "stop saying such idiocies, you're a f*cking moron", he
doesn't really mean that, he means that he's very disappointed that *that
person* says this or that, so he takes the time to say it to that person.
The proof is that most often in the next mail he explains to the person
how to do the thing right. He just tries to ensure that the person he's
telling words to understands that he/she has crossed a line.

Sure it can be hard for newcomers but I don't remember having read him
scold a newcomer. So that's probably not that much of a problem in the
end, and helps getting the things done in time. I'm much more concerned
by the "administrative" development mode that we're taking in fact and
that some people seem to have expressed in this thread (what patch flow
to follow, when to send/not to send, etc...).

BTW, I was amazed that you managed to get him have a much softer tone inr
his last e-mail, you probably found a weakness here in his management
process :-)

Best regards,
Willy

Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Mon, 2013-07-15 at 15:05 -0400, J. Bruce Fields wrote:

> "Nice", "subtle", and "polite" all seem mostly orthogonal to me.
> 

"Nice" and "polite" are rather attached. But "subtle" is orthogonal, as
in....


 "Fuck you, subtly"

-- Steve

Re: [ 00/19] 3.10.1-stable review

[Linus Torvalds]

On Mon, Jul 15, 2013 at 12:17 PM, Willy Tarreau <w@1wt.eu> wrote:
>
> BTW, I was amazed that you managed to get him have a much softer tone inr
> his last e-mail, you probably found a weakness here in his management
> process :-)

Hey, I _like_ arguing, and "cursing" and "arguing" are actually not at
all the same thing.

And I really don't tend to curse unless people are doing something
stupid and annoying. If people have concerns and questions that I feel
are valid, I'm more than happy to talk about it.

I curse when there isn't any argument. The cursing happens for the
"you're so f*cking wrong that it's not even worth trying to make
logical arguments about it, because you have no possible excuse" case.

.. and sometimes people surprise me and come back with a valid excuse
after all. "My whole family died in a tragic freak accident and my
pony got cancer, and I was distracted".

And then I might even tell them I'm sorry.

No. Not really.

           Linus

Re: [ 00/19] 3.10.1-stable review

[Willy Tarreau]

On Mon, Jul 15, 2013 at 12:23:05PM -0700, Linus Torvalds wrote:
> On Mon, Jul 15, 2013 at 12:17 PM, Willy Tarreau <w@1wt.eu> wrote:
> >
> > BTW, I was amazed that you managed to get him have a much softer tone inr
> > his last e-mail, you probably found a weakness here in his management
> > process :-)
> 
> Hey, I _like_ arguing, and "cursing" and "arguing" are actually not at
> all the same thing.
> 
> And I really don't tend to curse unless people are doing something
> stupid and annoying. If people have concerns and questions that I feel
> are valid, I'm more than happy to talk about it.

Oh I know, you've even kindly helped me a few times backporting fixes for
things I absolutely did not understand and took the time to explain to me.
So I have nothing against your communication mode, quite the opposite, and
people who know me know that mine has some similarities (a bit less extreme
in wording though). I'm used to say that I prefer to discuss with people who
I disagree with because they're those from whom there is more to learn, and
they're the most likely to make me change my opinions.

> I curse when there isn't any argument. The cursing happens for the
> "you're so f*cking wrong that it's not even worth trying to make
> logical arguments about it, because you have no possible excuse" case.
> 
> .. and sometimes people surprise me and come back with a valid excuse
> after all. "My whole family died in a tragic freak accident and my
> pony got cancer, and I was distracted".

Not a valid excuse, the patch should not have been sent in the first
place :-)

Willy

Re: [ 00/19] 3.10.1-stable review

[Sarah Sharp]

On Mon, Jul 15, 2013 at 12:07:56PM -0700, Linus Torvalds wrote:
> On Mon, Jul 15, 2013 at 11:46 AM, Sarah Sharp
> <sarah.a.sharp@linux.intel.com> wrote:
> >
> > Bullshit.  I've seen you be polite, and explain to clueless maintainers
> > why there's no way you can revert their merge that caused regressions,
> > and ask them to fit it without resorting to tearing them down
> > emotionally:
> 
> Oh, I'll be polite when it's called for.
> 
> But when people who know better send me crap, I'll curse at them.
> 
> I suspect you'll notice me cursing *way* more at top developers than
> random people on the list. I expect more from them, and conversely
> I'll be a lot more upset when they do something that I really think
> was not great.
> 
> For example, my latest cursing explosion was for the x86 maintainers,
> and it comes from the fact that I *know* they know to do better. The
> x86 tip pulls have generally been through way more testing than most
> other pulls I get (not just compiling, but even booting randconfigs
> etc). So when an x86 pull request comes in that clearly missed that
> expected level of quality, I go to town.

Good lord.  So anyone that is one of your "top maintainers" could be
exposed to your verbal abuse just because they "should have known
better"?

You know what the definition of an abuser is?  Someone that seeks out
victims that they know will "just take it" and keep the abuse "between
the two of them".  They pick victims that won't fight back or report the
abuse.

> Similarly, you will see fireworks if some long-term maintainer makes
> excuses for breaking user space etc. That will make me go into
> incoherent rages.
> 
> The "polite Linus" example that you point to? That was a maintainer
> asking for direction for when things went wrong and *before* sending
> me something dubious. Of course I'm polite then.
> 
> Sarah, I don't have Tourettes syndrome. You seem to think that my
> cursing is uncontrolled and random. I argue that it has causes. Big
> difference.

It does not matter if your cursing fits have causes.  The fact is that
if you misjudge someone's emotional state for the day, you yelling at
them is not productive.

In karate, or any other sport, if your opponent is motionless on the
floor, you stop.  You can't see the person you're emailing.  You can't
see if the first conversation-disabling blow has completely knocked them
out.  You can't see if you've misjudged their mental strength for the
day and completely wiped out their ability to use their brain to correct
the technical mistake you're trying to get them to fix.

Ask them to fix their mistake.  If they protest, then lay into them.  If
you *know* they don't take verbal abuse well, don't.

Let's get this personal baggage out of the way right now, before anyone
else brings it up:

I've been through verbal abuse before.  I won't take that shit from you,
or any of the other Linux kernel developers.  Tell me, politely, what I
have done wrong, and I will fix it.  You don't need to SHOUT, call me
names, or tell me to SHUT THE FUCK UP!

I'm not the only one that won't take verbal abuse.  Stop abusing your
developers.

Sarah Sharp

Re: [ 00/19] 3.10.1-stable review

[Sarah Sharp]

On Mon, Jul 15, 2013 at 12:53:16PM -0700, Sarah Sharp wrote:
> Good lord.  So anyone that is one of your "top maintainers" could be
> exposed to your verbal abuse just because they "should have known
> better"?
> 
> You know what the definition of an abuser is?  Someone that seeks out
> victims that they know will "just take it" and keep the abuse "between
> the two of them".  They pick victims that won't fight back or report the
> abuse.

Oh, FFS, I just called out on private email for "playing the victim
card".  I will repeat: this is not just about me, or other minorities.
I should not have to ask for professional behavior on the mailing lists.
Professional behavior should be the default.

"The standard you walk past is the standard you accept."

http://www.smh.com.au/federal-politics/political-news/unlikely-feminist-hero-army-chiefs-video-message-draws-plaudits-20130614-2o86b.html

"Those who think that it is ok to behave in a way that demeans or
exploits their colleagues have no place in this army. If that does not
suit you, then get out.

The same goes for those that think that toughness is built on
humiliating others.  Every one of us is responsible for the culture and
reputation of our Army, and the environment in which we work. If you
become aware of any individual degrading another, then show moral
courage and take a stand against it."

> In karate, or any other sport, if your opponent is motionless on the
> floor, you stop.  You can't see the person you're emailing.  You can't
> see if the first conversation-disabling blow has completely knocked them
> out.  You can't see if you've misjudged their mental strength for the
> day and completely wiped out their ability to use their brain to correct
> the technical mistake you're trying to get them to fix.
> 
> Ask them to fix their mistake.  If they protest, then lay into them.  If
> you *know* they don't take verbal abuse well, don't.

Sarah Sharp

Re: [ 00/19] 3.10.1-stable review

[Kees Cook]

On Mon, Jul 15, 2013 at 01:41:35PM -0700, Sarah Sharp wrote:
> "The standard you walk past is the standard you accept."

I think this sums up the situation very well. Even if we accept that some
people can "correctly" choose when to be abusive, it creates an atmosphere
where other people will come to think that kind of thing is okay.

I always enjoyed this presentation about maintaining a good social tone
in an online community:
http://www.slideshare.net/vishnu/how-to-protect-yourhow-to-protect-your-open-source-project-from-poisonous-people

People's mistakes can be pointed out without the kind of abuse I've
read on lkml. People need to know the severity of problems they create,
and almost never are those problems _intentional_ (which would still
require one to one accept that it's okay to be abusive as a form of
"self defense"). Expecting people to change their behaviors, methods, or
practices in order to avoid mistakes seems like a reasonable thing. This
is how I've tried to fix my stupid mistakes when I encounter them or
they're pointed out.

When someone cuts me off in traffic, I assume they're oblivious rather
than malicious. If I drove 8 hours a day, I'm sure my resolve to accept
and understand these mistakes would erode over time, but I still think
it would be more productive to let them know it was uncool with a short
honk rather than trying to ram them. :)

-Kees

-- 
Kees Cook                                            @outflux.net

Re: [ 00/19] 3.10.1-stable review

[Linus Torvalds]

On Mon, Jul 15, 2013 at 1:41 PM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
>
> Oh, FFS, I just called out on private email for "playing the victim
> card".  I will repeat: this is not just about me, or other minorities.
> I should not have to ask for professional behavior on the mailing lists.
> Professional behavior should be the default.

Bullshit.

The thing is, the "victim card" is exactly about trying to enforce
your particular expectations on others, and trying to do so in a very
particular way. It's the old "think of the children" argument.  And
it's bogus.  Calling things "professional" is just more of the same -
trying to enforce some kind of convention on others by trying to claim
that it's the only acceptable way.

  [ Since you seem to want to keep this in public, I'll just
cut-and-paste from my reply, so you have already seen this part of my
argument, it's only slightly edited because now I'm no longer typing
on my cellphone ]

The thing is, different people act and react differently. On both
sides. And I think we should recognize that and also *allow* for that.
And sometimes it means, for example, that people interact primarily
with certain people that they like more - because they are a better
"fit".

I think we actually do it very naturally, simply because we are human,
and this is how people interact in real life too. Sometimes we do it
consciously - the way we have people at various companies that act as
go-betweens - but most of the time we do it just because humans are
all about social interactions and we don't even think about what we do
and why.

For example, you work mostly through Greg. I don't think either of you
*planned* it that way, but it's likely because you guys work well
together.

See what I'm saying? People are different. I'm not polite, and I get
upset easily but generally don't hold a grudge - I have these
explosive emails. And that works well for some people. And it probably
doesn't work well with you.

And you know what? That's fine. Not everybody had to get along or work
well with each other. But the fact that it doesn't work with you
doesn't make it "wrong".

This isn't all that different from working around language issues etc
by having certain people work as in-betweens on that front.

And where we differ is in thinking either side has to necessarily
change. You think people need to act "nicer". While I think it's
*natural* that people have different behavior - and different
expectations. We all have issues somewhere and don't all like each
other. There are certain people I refuse to work with, for example.
They may be good engineers, but they just aren't people I can work
with.

And hey, I don't actually think we've personally even had any
problems. And I realize that you may react very strongly and get
nervous about us having problems, but realistically, do you actually
expect to like all the other kernel engineers?

And equally importantly, not everybody has to like you, or necessarily
think they have to be liked by you. OK?

So as far as I'm concerned, the discussion is about "how to work
together DESPITE people being different". Not about trying to make
everybody please each other. Because I can pretty much guarantee that
I'll continue cursing. To me, the discussion would be about how to
work together despite these kinds of cultural differences, not about
"how do we make everybody nice and sing songs sound the campfire"

Do you think you might be interested in *that* kind of discussion
instead of the "you are abusing me" kind of discussion?

Because if you want me to "act professional", I can tell you that I'm
not interested. I'm sitting in my home office wearign a bathrobe. The
same way I'm not going to start wearing ties, I'm *also* not going to
buy into the fake politeness, the lying, the office politics and
backstabbing, the passive aggressiveness, and the buzzwords. Because
THAT is what "acting professionally" results in: people resort to all
kinds of really nasty things because they are forced to act out their
normal urges in unnatural ways.

               Linus

[ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Steven Rostedt]

On Mon, 2013-07-15 at 14:50 -0700, Linus Torvalds wrote:
> On Mon, Jul 15, 2013 at 1:41 PM, Sarah Sharp
> <sarah.a.sharp@linux.intel.com> wrote:
> >
> > Oh, FFS, I just called out on private email for "playing the victim
> > card".  I will repeat: this is not just about me, or other minorities.
> > I should not have to ask for professional behavior on the mailing lists.
> > Professional behavior should be the default.
> 
> Bullshit.
> 

Can we please make this into a Kernel Summit discussion. I highly doubt
we would solve anything, but it certainly would be a fun segment to
watch :-)

-- Steve

Re: [ATTEND] How to act on LKML

[Randy Dunlap]

On 07/15/13 15:08, Steven Rostedt wrote:
> On Mon, 2013-07-15 at 14:50 -0700, Linus Torvalds wrote:
>> On Mon, Jul 15, 2013 at 1:41 PM, Sarah Sharp
>> <sarah.a.sharp@linux.intel.com> wrote:
>>>
>>> Oh, FFS, I just called out on private email for "playing the victim
>>> card".  I will repeat: this is not just about me, or other minorities.
>>> I should not have to ask for professional behavior on the mailing lists.
>>> Professional behavior should be the default.
>>
>> Bullshit.
>>
> 
> Can we please make this into a Kernel Summit discussion. I highly doubt
> we would solve anything, but it certainly would be a fun segment to
> watch :-)


Surely.  I would love to watch it also...
<end multi-sarcasm>

-- 
~Randy

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Sarah Sharp]

On Mon, Jul 15, 2013 at 06:08:29PM -0400, Steven Rostedt wrote:
> On Mon, 2013-07-15 at 14:50 -0700, Linus Torvalds wrote:
> > On Mon, Jul 15, 2013 at 1:41 PM, Sarah Sharp
> > <sarah.a.sharp@linux.intel.com> wrote:
> > >
> > > Oh, FFS, I just called out on private email for "playing the victim
> > > card".  I will repeat: this is not just about me, or other minorities.
> > > I should not have to ask for professional behavior on the mailing lists.
> > > Professional behavior should be the default.
> > 
> > Bullshit.
> > 
> 
> Can we please make this into a Kernel Summit discussion. I highly doubt
> we would solve anything, but it certainly would be a fun segment to
> watch :-)

I agree, KS is where this conversation should be taking place.
Attendees for this conversation (so far) should be Greg KH, Linus,
Darren Hart, Steve Rostedt, Willy Tarreau, and me.

> > So as far as I'm concerned, the discussion is about "how to work
> > together DESPITE people being different". Not about trying to make
> > everybody please each other. Because I can pretty much guarantee that
> > I'll continue cursing. To me, the discussion would be about how to
> > work together despite these kinds of cultural differences, not about
> > "how do we make everybody nice and sing songs sound the campfire"
> > 
> > Do you think you might be interested in *that* kind of discussion
> > instead of the "you are abusing me" kind of discussion?
> > 
> > Because if you want me to "act professional", I can tell you that I'm
> > not interested. I'm sitting in my home office wearign a bathrobe. The
> > same way I'm not going to start wearing ties, I'm *also* not going to
> > buy into the fake politeness, the lying, the office politics and
> > backstabbing, the passive aggressiveness, and the buzzwords. Because
> > THAT is what "acting professionally" results in: people resort to all
> > kinds of really nasty things because they are forced to act out their
> > normal urges in unnatural ways.

Yes, let's move this conversation into the "how to work together DESPITE
people being different" realm.  I would be happy to have that
discussion.  As Linus said, some people work together better than
others.  Some people have different expectations of appropriate ways to
interact with co-workers.  Sometimes that means that people only work
with certain other co-workers, like Greg and I.

The people who want to work together in a civil manner should get
together and create a "Kernel maintainer's code of conduct" that
outlines what they expect from fellow kernel developers.  The people who
want to continue acting "unprofessionally" should document what
behaviors set off their cursing streaks, so that others can avoid that
behavior.  Somewhere in the middle is the community behavior all
developers can thrive in.

Some people won't agree with everything in that document.  The point is,
they don't have to agree.  They can read the document, figure out what
the community expects, and figure out whether they can modify their
behavior to match.  If they are unwilling to change, they simply don't
have to work with the developers who have signed it.

Perhaps a trusted third party could take a stab at a first draft of this
document?  Greg KH?  Steve Rostedt?  Darren Hart?

Sarah Sharp

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Linus Torvalds]

On Mon, Jul 15, 2013 at 3:08 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> Can we please make this into a Kernel Summit discussion. I highly doubt
> we would solve anything, but it certainly would be a fun segment to
> watch :-)

I think we should, because I think it's the kind of thing we really
need at the KS - talking about "process".

At the same time, I really don't know what the format would possibly
be like for it to really work as a reasonable discussion. And I think
that is important, because this kind of subject is *not* likely
possible in the traditional "people sit around tables and maybe
somebody has a few slides" format.

A small panel discussion with a few people (fiveish?) that have very
different viewpoints, along with baskets of rotten fruit set out on
the tables? That could be fun. And I'm serious, although we might want
to limit the size of the fruit to smaller berries ;)

Sarah will bring the brownies.

               Linus

Re: [ 00/19] 3.10.1-stable review

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]

On Mon, 15 Jul 2013 21:17:27 +0200 Willy Tarreau <w@1wt.eu> wrote:

> Communication works two ways.

I understand that to mean (at least) that for communication, every message
must be both sent and received.  So when constructing a message, it is
important to think about how others will understand it.
On a public email list there are an awful lot of "others", and it is very
likely that any possible misunderstanding will be experienced by someone.
I think it best to minimise opportunities for misunderstanding.

> 
> Sure it can be hard for newcomers but I don't remember having read him
> scold a newcomer. 

I think that is not relevant.  He is scolding people senior developers in
front of newcomers.  That is not likely to encourage people to want to become
senior developers.

Anecdote:  My son (in highschool) is doing a psych assignment where he is
asking people to complete a survey which, among other things, asks about
people fear/anxiety response to various situations (it is a fairly standard
instrument I think[1]).  Last few times he checked, the situation with the
highest average score was "One person bullying another".  Really, it isn't
nice to watch.

NeilBrown

[1] e.g.
http://horan.asu.edu/ced522readings/ced-fearquestionnaire.htm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Sarah Sharp]

On Mon, Jul 15, 2013 at 03:38:42PM -0700, Linus Torvalds wrote:
> On Mon, Jul 15, 2013 at 3:08 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > Can we please make this into a Kernel Summit discussion. I highly doubt
> > we would solve anything, but it certainly would be a fun segment to
> > watch :-)
> 
> I think we should, because I think it's the kind of thing we really
> need at the KS - talking about "process".
> 
> At the same time, I really don't know what the format would possibly
> be like for it to really work as a reasonable discussion. And I think
> that is important, because this kind of subject is *not* likely
> possible in the traditional "people sit around tables and maybe
> somebody has a few slides" format.
> 
> A small panel discussion with a few people (fiveish?) that have very
> different viewpoints, along with baskets of rotten fruit set out on
> the tables? That could be fun. And I'm serious, although we might want
> to limit the size of the fruit to smaller berries ;)
> 
> Sarah will bring the brownies.

Peace pot brownies!  I love it!

Sarah Sharp

Re: [ 00/19] 3.10.1-stable review

[Raymond Jennings]

On Mon, 2013-07-15 at 12:23 -0700, Linus Torvalds wrote:
> On Mon, Jul 15, 2013 at 12:17 PM, Willy Tarreau <w@1wt.eu> wrote:
> >
> > BTW, I was amazed that you managed to get him have a much softer tone inr
> > his last e-mail, you probably found a weakness here in his management
> > process :-)
> 
> Hey, I _like_ arguing, and "cursing" and "arguing" are actually not at
> all the same thing.
> 
> And I really don't tend to curse unless people are doing something
> stupid and annoying. If people have concerns and questions that I feel
> are valid, I'm more than happy to talk about it.
> 
> I curse when there isn't any argument. The cursing happens for the
> "you're so f*cking wrong that it's not even worth trying to make
> logical arguments about it, because you have no possible excuse" case.
> 
> .. and sometimes people surprise me and come back with a valid excuse
> after all. "My whole family died in a tragic freak accident and my
> pony got cancer, and I was distracted".

...At least with the recent SCOTUS ruling, if you took your pony to a
vet you wouldn't have to worry about Hasbro suing him for patent
infringement...

> And then I might even tell them I'm sorry.
> 
> No. Not really.
> 
>            Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Guenter Roeck]

On Mon, Jul 15, 2013 at 03:36:15PM -0700, Sarah Sharp wrote:
> On Mon, Jul 15, 2013 at 06:08:29PM -0400, Steven Rostedt wrote:
> > On Mon, 2013-07-15 at 14:50 -0700, Linus Torvalds wrote:
> > > On Mon, Jul 15, 2013 at 1:41 PM, Sarah Sharp
> > > <sarah.a.sharp@linux.intel.com> wrote:
> > > >
> > > > Oh, FFS, I just called out on private email for "playing the victim
> > > > card".  I will repeat: this is not just about me, or other minorities.
> > > > I should not have to ask for professional behavior on the mailing lists.
> > > > Professional behavior should be the default.
> > > 
> > > Bullshit.
> > > 
> > 
> > Can we please make this into a Kernel Summit discussion. I highly doubt
> > we would solve anything, but it certainly would be a fun segment to
> > watch :-)
> 
> I agree, KS is where this conversation should be taking place.
> Attendees for this conversation (so far) should be Greg KH, Linus,
> Darren Hart, Steve Rostedt, Willy Tarreau, and me.
> 
One thing you should keep in mind in your discussion is what can happen
if people get too polite with each other.

I have seen this happen at two large companies I worked for. Early on, flames
are acceptable and expected as response to someone publishing bad code which
breaks everything for everyone. Then, at some point, it is not acceptable
anymore to flame, and one is expected to be polite and friendly at all times.
"Your code breaks the build for every platform. Would you please kindly
consider fixing it ?"
Result is that code quality suffers, to the point where images don't even
build anymore.

I hope the Linux kernel never gets into that stage. To avoid that,
I am willing to be cursed at by Linus if I am the responsible party.

Guenter

Re: [ 00/19] 3.10.1-stable review

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

On Mon, 15 Jul 2013 15:19:44 -0400 Steven Rostedt <rostedt@goodmis.org> wrote:

> On Mon, 2013-07-15 at 15:05 -0400, J. Bruce Fields wrote:
> 
> > "Nice", "subtle", and "polite" all seem mostly orthogonal to me.
> > 
> 
> "Nice" and "polite" are rather attached.

Being "polite" without being "nice" is quite possible.  It even has a name:
 Diplomacy.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Darren Hart]

On Mon, 2013-07-15 at 15:36 -0700, Sarah Sharp wrote:
> On Mon, Jul 15, 2013 at 06:08:29PM -0400, Steven Rostedt wrote:
> > On Mon, 2013-07-15 at 14:50 -0700, Linus Torvalds wrote:
> > > On Mon, Jul 15, 2013 at 1:41 PM, Sarah Sharp
> > > <sarah.a.sharp@linux.intel.com> wrote:
> > > >
> > > > Oh, FFS, I just called out on private email for "playing the victim
> > > > card".  I will repeat: this is not just about me, or other minorities.
> > > > I should not have to ask for professional behavior on the mailing lists.
> > > > Professional behavior should be the default.
> > > 
> > > Bullshit.
> > > 
> > 
> > Can we please make this into a Kernel Summit discussion. I highly doubt
> > we would solve anything, but it certainly would be a fun segment to
> > watch :-)
> 
> I agree, KS is where this conversation should be taking place.
> Attendees for this conversation (so far) should be Greg KH, Linus,
> Darren Hart, Steve Rostedt, Willy Tarreau, and me.
> 
> > > So as far as I'm concerned, the discussion is about "how to work
> > > together DESPITE people being different". Not about trying to make
> > > everybody please each other. Because I can pretty much guarantee that
> > > I'll continue cursing. To me, the discussion would be about how to
> > > work together despite these kinds of cultural differences, not about
> > > "how do we make everybody nice and sing songs sound the campfire"
> > > 
> > > Do you think you might be interested in *that* kind of discussion
> > > instead of the "you are abusing me" kind of discussion?
> > > 
> > > Because if you want me to "act professional", I can tell you that I'm
> > > not interested. I'm sitting in my home office wearign a bathrobe. The
> > > same way I'm not going to start wearing ties, I'm *also* not going to
> > > buy into the fake politeness, the lying, the office politics and
> > > backstabbing, the passive aggressiveness, and the buzzwords. Because
> > > THAT is what "acting professionally" results in: people resort to all
> > > kinds of really nasty things because they are forced to act out their
> > > normal urges in unnatural ways.
> 
> Yes, let's move this conversation into the "how to work together DESPITE
> people being different" realm.  I would be happy to have that
> discussion.  As Linus said, some people work together better than
> others.  Some people have different expectations of appropriate ways to
> interact with co-workers.  Sometimes that means that people only work
> with certain other co-workers, like Greg and I.
> 
> The people who want to work together in a civil manner should get
> together and create a "Kernel maintainer's code of conduct" that
> outlines what they expect from fellow kernel developers.  The people who
> want to continue acting "unprofessionally" should document what
> behaviors set off their cursing streaks, so that others can avoid that
> behavior.  Somewhere in the middle is the community behavior all
> developers can thrive in.
> 
> Some people won't agree with everything in that document.  The point is,
> they don't have to agree.  They can read the document, figure out what
> the community expects, and figure out whether they can modify their
> behavior to match.  If they are unwilling to change, they simply don't
> have to work with the developers who have signed it.
> 
> Perhaps a trusted third party could take a stab at a first draft of this
> document?  Greg KH?  Steve Rostedt?  Darren Hart?
> 

Well, I admit this wasn't the contribution I've been working toward for
my first KS invite, but if people think this would be valuable, I'm up
for helping out where I can. Now are we talking more about a code of
conduct or a process document. I'm more likely to help out on the
latter, as the former often raises my hackles a bit. I'm fine with a
few lines in the process document instructing people on the pitfalls of
written communication and to keep it civil, but I will not enumerate
the seven words you can't say on television as bad words that thou
shalt no use. Such a document would be largely ignored, and indeed, may
have the opposite of the desired result :-)

I do believe that someone from the intended audience of a document
should be the one to write the first draft (or they should be among the
reviewers if the authority drafts the document). For instance, I
believe I would be able to document how to work with -tip or -stable as
an individual contributor. I would not be a good candidate for writing
the "how to be a lieutenant to Linus" because I am neither Linus nor
one of his lieutenants. I concern myself with Thomas, Ingo, Peter Z.,
and Greg K-H, and increasingly David Miller, but I don't worry about
Linus because I trust these people to do that properly and I trust that
their rules are the ones I need to follow: if it's good enough for
them, it will make upstream eventually.

I will re-iterate one more time though, that personally, I am much more
interested in making it clear what sets people (OK, Linus) off in a
document like stable_kernel_rules where we can point violators to. A
document which eliminates the need to search LKML or -stable for
similar patches to determine the preferred process of the month. Where
possible, this would (IMO) be the default policy document and subsystem
maintainers would only deviate from it for very good reasons. For
example, having different comment formatting rules in checkpatch for
different subsystems strikes me as cruel and unusual. If someone goes on
a tirade for a violation that is not documented, the blame falls on them
IMHO. If it's documented, a newcomer gets a referral, a repeat offender
has opened themselves up to stronger forms of persuasion.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

Re: [ 00/19] 3.10.1-stable review

[Joe Perches]

On Tue, 2013-07-16 at 09:42 +1000, NeilBrown wrote:
> Being "polite" without being "nice" is quite possible.
> It even has a name:  Diplomacy.

And we all know how circular/indirect/implied/useless
some of those diplomatic conversations can be.

Just remember to bring a 'Big Stick' and don't be shy
when it's necessary to display it.

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Steven Rostedt]

On Mon, 2013-07-15 at 16:15 -0700, Guenter Roeck wrote:
>  
> One thing you should keep in mind in your discussion is what can happen
> if people get too polite with each other.
> 
> I have seen this happen at two large companies I worked for. Early on, flames
> are acceptable and expected as response to someone publishing bad code which
> breaks everything for everyone. Then, at some point, it is not acceptable
> anymore to flame, and one is expected to be polite and friendly at all times.
> "Your code breaks the build for every platform. Would you please kindly
> consider fixing it ?"
> Result is that code quality suffers, to the point where images don't even
> build anymore.
> 
> I hope the Linux kernel never gets into that stage. To avoid that,
> I am willing to be cursed at by Linus if I am the responsible party.

Didn't Jim Zemlin show some research where there were two groups:

 One that did a bunch of brain storming where no idea was a bad idea

 The other required you to defend your idea while the others bashed it.

The results always showed that the second group not only did a better
job, but also faster and more efficient.

I'm afraid if we worry too much about politeness, we will fall into that
first group.

-- Steve

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Raymond Jennings]

On Mon, 2013-07-15 at 15:38 -0700, Linus Torvalds wrote:
> On Mon, Jul 15, 2013 at 3:08 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > Can we please make this into a Kernel Summit discussion. I highly doubt
> > we would solve anything, but it certainly would be a fun segment to
> > watch :-)
> 
> I think we should, because I think it's the kind of thing we really
> need at the KS - talking about "process".
> 
> At the same time, I really don't know what the format would possibly
> be like for it to really work as a reasonable discussion. And I think
> that is important, because this kind of subject is *not* likely
> possible in the traditional "people sit around tables and maybe
> somebody has a few slides" format.
> 
> A small panel discussion with a few people (fiveish?) that have very
> different viewpoints, along with baskets of rotten fruit set out on
> the tables? That could be fun. And I'm serious, although we might want
> to limit the size of the fruit to smaller berries ;)
> 
> Sarah will bring the brownies.

I'm sure slashdot will be happy to follow up, seeing as how this heated
discussion just made headlines there.

http://linux.slashdot.org/story/13/07/15/2316219/kernel-dev-tells-linus-torvalds-to-stop-using-abusive-language

Personally I *like* when abusive language is used, assuming it's used
appropriately.  I *hate very much* when people are nice to me and let
their frustrations grow, only to ambush me later with a string of curses
and lashings in one fell swoop.  Not only does "holding it in" set me up
for failure becuase I remain ignorant, I also feel downright betrayed
when they come off as vindictive bastards that saved their beefs until
the moment was ripe to do the most damage.  It doesn't just make me lose
respect for them, it makes me lose trust.

Give me an honest asshole over a silver tongued backstabber any day.

>                Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 00/19] 3.10.1-stable review

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

On Mon, 15 Jul 2013 16:50:52 -0700 Joe Perches <joe@perches.com> wrote:

> On Tue, 2013-07-16 at 09:42 +1000, NeilBrown wrote:
> > Being "polite" without being "nice" is quite possible.
> > It even has a name:  Diplomacy.
> 
> And we all know how circular/indirect/implied/useless
> some of those diplomatic conversations can be.
> 
> Just remember to bring a 'Big Stick' and don't be shy
> when it's necessary to display it.

The behaviour you appear to be advocating is what is generally called
"bullying".  I think that is what started this thread.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ 00/19] 3.10.1-stable review

[Joe Perches]

On Tue, 2013-07-16 at 11:54 +1000, NeilBrown wrote:
> On Mon, 15 Jul 2013 16:50:52 -0700 Joe Perches <joe@perches.com> wrote:
> 
> > On Tue, 2013-07-16 at 09:42 +1000, NeilBrown wrote:
> > > Being "polite" without being "nice" is quite possible.
> > > It even has a name:  Diplomacy.
> > 
> > And we all know how circular/indirect/implied/useless
> > some of those diplomatic conversations can be.
> > 
> > Just remember to bring a 'Big Stick' and don't be shy
> > when it's necessary to display it.
> 
> The behaviour you appear to be advocating is what is generally called
> "bullying".

Nope.  It's called not being a pushover and being
direct, clear and not just being unnecessarily forceful.

I also think that depends on "when it's necessary".
That comes after speaking softly, multiple times.

cheers, Joe

Re: [ATTEND] How to act on LKML

[Chris Ball]

Hi,

On Tue, Jul 16 2013, Darren Hart wrote:
> On Mon, 2013-07-15 at 15:36 -0700, Sarah Sharp wrote:
>> The people who want to work together in a civil manner should get
>> together and create a "Kernel maintainer's code of conduct" that
>> outlines what they expect from fellow kernel developers.  The people who
>> want to continue acting "unprofessionally" should document what
>> behaviors set off their cursing streaks, so that others can avoid that
>> behavior.  Somewhere in the middle is the community behavior all
>> developers can thrive in.
>> 
>> Some people won't agree with everything in that document.  The point is,
>> they don't have to agree.  They can read the document, figure out what
>> the community expects, and figure out whether they can modify their
>> behavior to match.  If they are unwilling to change, they simply don't
>> have to work with the developers who have signed it.
>> 
>> Perhaps a trusted third party could take a stab at a first draft of this
>> document?  Greg KH?  Steve Rostedt?  Darren Hart?
>
> [..]
> I do believe that someone from the intended audience of a document
> should be the one to write the first draft (or they should be among the
> reviewers if the authority drafts the document). For instance, I
> believe I would be able to document how to work with -tip or -stable as
> an individual contributor. I would not be a good candidate for writing
> the "how to be a lieutenant to Linus" because I am neither Linus nor
> one of his lieutenants.

Here's a simple statement that I hope many kernel developers would
sign up for -- I'd be happy to make it for the subsystem I maintain:

* If there's something wrong with your patch, I will critique the
  code respectfully, without personal attacks or public humiliation.

I'd like other developers to treat me this way too, but perhaps a good
way to get started is to first come up with a statement of how we'd
like to treat others, and then start collecting signatories to it.
Does that sound like a good idea?

Thanks,

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>

Re: [ 00/19] 3.10.1-stable review

[Li Zefan]

>> Sarah, first off, I don't have that many tools at hand. Secondly, I
>> simply don't believe in being polite or politically correct.
> 
> Bullshit.  I've seen you be polite, and explain to clueless maintainers
> why there's no way you can revert their merge that caused regressions,
> and ask them to fit it without resorting to tearing them down
> emotionally:
> 

As an asian, who are considered as much shyer than Western developers,
I don't see any attitute problem in Linus. But whenever I need to send
a patch to him, I tend to be more careful not to make mistakes.

Re: [ATTEND] How to act on LKML

[Steven Rostedt]

On Tue, 2013-07-16 at 03:43 +0100, Chris Ball wrote:
> Hi,

> I'd like other developers to treat me this way too, but perhaps a good
> way to get started is to first come up with a statement of how we'd
> like to treat others, and then start collecting signatories to it.
> Does that sound like a good idea?

"collecting signatories"? Like getting signatures from kids that say
they will remain virgins till they marry? In the end, they all end up
getting screwed.

No, we don't need any pact to sign. I'm not sure this is really that
much of an issue. Yes, Linus likes to rant, but that's basically his
trademark. There's a few other grumpy kernel developers that can be a
bit heavy handed too. But really, if you don't want to be cursed at,
here's some pretty easy instructions to follow.


1) Read what a maintainer tells you twice. If you are pointed to a
document, read that twice.

2) If you don't understand what the maintainer says, ask what he/she
meant.

3) Be honest! Don't try to pull that you know something that you really
don't.

4) If you change existing infrastructure. Prove that your change is
better. And not just on your box, on many other boxes. Post RFCs asking
others to test, and give feedback. Don't claim its better till the
numbers are in.

5) Don't be afraid to admit you don't know something. I find people that
tell you what they don't know have much more integrity than people that
keep telling you what they do know.

I don't see any kernel developer cursing at someone because they just
feel like cursing at someone. It's usually caused by someone not being
honest with themselves or the developers they are dealing with. Or
simply not listening to what they are being told.

Linus's point is that he wants to be honest, and cursing is his way of
giving you the most direct way to understand how he honestly feels.

-- Steve

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1618 bytes --]

On Mon, 15 Jul 2013 20:17:30 -0400 Steven Rostedt <rostedt@goodmis.org> wrote:

> On Mon, 2013-07-15 at 16:15 -0700, Guenter Roeck wrote:
> >  
> > One thing you should keep in mind in your discussion is what can happen
> > if people get too polite with each other.
> > 
> > I have seen this happen at two large companies I worked for. Early on, flames
> > are acceptable and expected as response to someone publishing bad code which
> > breaks everything for everyone. Then, at some point, it is not acceptable
> > anymore to flame, and one is expected to be polite and friendly at all times.
> > "Your code breaks the build for every platform. Would you please kindly
> > consider fixing it ?"
> > Result is that code quality suffers, to the point where images don't even
> > build anymore.
> > 
> > I hope the Linux kernel never gets into that stage. To avoid that,
> > I am willing to be cursed at by Linus if I am the responsible party.
> 
> Didn't Jim Zemlin show some research where there were two groups:
> 
>  One that did a bunch of brain storming where no idea was a bad idea
> 
>  The other required you to defend your idea while the others bashed it.
> 
> The results always showed that the second group not only did a better
> job, but also faster and more efficient.
> 
> I'm afraid if we worry too much about politeness, we will fall into that
> first group.
> 

Surely there is an enormous difference between being required to defend your
position against rational and forceful argument, and being required to defend
it against irrelevant name calling.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ATTEND] How to act on LKML

[Li Zefan]

On 2013/7/16 6:08, Steven Rostedt wrote:
> On Mon, 2013-07-15 at 14:50 -0700, Linus Torvalds wrote:
>> On Mon, Jul 15, 2013 at 1:41 PM, Sarah Sharp
>> <sarah.a.sharp@linux.intel.com> wrote:
>>>
>>> Oh, FFS, I just called out on private email for "playing the victim
>>> card".  I will repeat: this is not just about me, or other minorities.
>>> I should not have to ask for professional behavior on the mailing lists.
>>> Professional behavior should be the default.
>>
>> Bullshit.
>>
> 
> Can we please make this into a Kernel Summit discussion. I highly doubt
> we would solve anything, but it certainly would be a fun segment to
> watch :-)
> 

Oh, I can name some kernel developers who I see are most friendly to other
developers, and you are one of them. ;)

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Steven Rostedt]

On Tue, 2013-07-16 at 13:14 +1000, NeilBrown wrote:

> Surely there is an enormous difference between being required to defend your
> position against rational and forceful argument, and being required to defend
> it against irrelevant name calling.

Sure, but I don't think there's really much name calling in the kernel
community.

I just scanned a large number of LKML emails, and they all seemed rather
technical, and no personal attacks at all. And that included several
emails from Linus as well. Probably the strongest email came from Thomas
Gleixner, but even that didn't contain any personal name calling. Mostly
he called stuff "crap" but that was about the code and claims that the
code did, but not about the person.

There are a few times that Linus gets a bit colorful with his
criticisms, but that's really the minority of the email and not the
overall tone. I think Linus picks his battles. Sometimes he goes
overboard, but he's human. But I still think he's running this ship
well.

-- Steve
	

Re: [ATTEND] How to act on LKML

[H. Peter Anvin]

On 07/15/2013 08:06 PM, Steven Rostedt wrote:
> 
> Linus's point is that he wants to be honest, and cursing is his way of
> giving you the most direct way to understand how he honestly feels.
> 

What I don't get about anything of this is that I have always found
Linus' being hyper-obviously over the top sarcastic when he goes on a
rant.  There is usually plenty of context to derive that from, too, even
if you haven't seen him in person enough to virtually hear the smirk in
his voice.  This is a form of humor more than anything else, and at
least I find it utterly impossible to be offended by it.  As the main
target of the rant this weekend, I (a) chuckled, and (b) said "I think I
need to do some damage control".

	-hpa

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Steven Rostedt]

On Mon, 2013-07-15 at 23:34 -0400, Steven Rostedt wrote:
> On Tue, 2013-07-16 at 13:14 +1000, NeilBrown wrote:
> 
> > Surely there is an enormous difference between being required to defend your
> > position against rational and forceful argument, and being required to defend
> > it against irrelevant name calling.
> 
> Sure, but I don't think there's really much name calling in the kernel
> community.
> 
> I just scanned a large number of LKML emails, and they all seemed rather
> technical, and no personal attacks at all. And that included several
> emails from Linus as well. Probably the strongest email came from Thomas
> Gleixner, but even that didn't contain any personal name calling. Mostly
> he called stuff "crap" but that was about the code and claims that the
> code did, but not about the person.
> 
> There are a few times that Linus gets a bit colorful with his
> criticisms, but that's really the minority of the email and not the
> overall tone. I think Linus picks his battles. Sometimes he goes
> overboard, but he's human. But I still think he's running this ship
> well.
> 

I just found this gem: https://lkml.org/lkml/2013/7/10/600

But it's just Linus ranting about having "make install" modify the
source tree (which I totally agree with him, as I've stumbled over crap
like this in other projects). But he's bitching about the code, not the
person who asked him to pull it.

-- Steve

Re: [ATTEND] How to act on LKML

[Steven Rostedt]

On Tue, 2013-07-16 at 11:27 +0800, Li Zefan wrote:

> Oh, I can name some kernel developers who I see are most friendly to other
> developers, and you are one of them. ;)

That's because I've been blessed to only have to deal with good
developers ;-)

-- Steve

Re: [ATTEND] How to act on LKML

[David Ahern]

On 7/15/13 4:50 PM, Sarah Sharp wrote:
>> Sarah will bring the brownies.
>
> Peace pot brownies!  I love it!

Too bad the KS is not going to be held here in Colorado. You could 
follow through with that ...

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Darren Hart]

On Mon, 2013-07-15 at 23:37 -0400, Steven Rostedt wrote:
> On Mon, 2013-07-15 at 23:34 -0400, Steven Rostedt wrote:
> > On Tue, 2013-07-16 at 13:14 +1000, NeilBrown wrote:
> > 
> > > Surely there is an enormous difference between being required to defend your
> > > position against rational and forceful argument, and being required to defend
> > > it against irrelevant name calling.
> > 
> > Sure, but I don't think there's really much name calling in the kernel
> > community.
> > 
> > I just scanned a large number of LKML emails, and they all seemed rather
> > technical, and no personal attacks at all. And that included several
> > emails from Linus as well. Probably the strongest email came from Thomas
> > Gleixner, but even that didn't contain any personal name calling. Mostly
> > he called stuff "crap" but that was about the code and claims that the
> > code did, but not about the person.
> > 
> > There are a few times that Linus gets a bit colorful with his
> > criticisms, but that's really the minority of the email and not the
> > overall tone. I think Linus picks his battles. Sometimes he goes
> > overboard, but he's human. But I still think he's running this ship
> > well.
> > 
> 
> I just found this gem: https://lkml.org/lkml/2013/7/10/600
> 
> But it's just Linus ranting about having "make install" modify the
> source tree (which I totally agree with him, as I've stumbled over crap
> like this in other projects). But he's bitching about the code, not the
> person who asked him to pull it.

Excellent example Steve. This is the core of what I was trying to get
at. Linus vehemently and colorfully expressed his distate for *problem*
and told the developer what they needed to do differently. No personal
attack there.

Would I like to be on the receiving end of that email... No, I would
not. However, I can also understand being fed up with lots of little
things like this and not having the patience or the desire to treat each
one as a mentoring opportunity. The difference tends to be I rant to my
close friends and Linus does so in public.... he's the more honest of
the two of us I think :-)

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

Re: [ 00/19] 3.10.1-stable review

[Rusty Russell]

Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, Jul 15, 2013 at 12:17 PM, Willy Tarreau <w@1wt.eu> wrote:
>>
>> BTW, I was amazed that you managed to get him have a much softer tone inr
>> his last e-mail, you probably found a weakness here in his management
>> process :-)
>
> Hey, I _like_ arguing, and "cursing" and "arguing" are actually not at
> all the same thing.
>
> And I really don't tend to curse unless people are doing something
> stupid and annoying. If people have concerns and questions that I feel
> are valid, I'm more than happy to talk about it.
>
> I curse when there isn't any argument. The cursing happens for the
> "you're so f*cking wrong that it's not even worth trying to make
> logical arguments about it, because you have no possible excuse" case.
>
> .. and sometimes people surprise me and come back with a valid excuse
> after all. "My whole family died in a tragic freak accident and my
> pony got cancer, and I was distracted".
>
> And then I might even tell them I'm sorry.
>
> No. Not really.

You have to be harsh with code: People mistake politeness for
uncertainty.  Whenever I said 'I prefer if you XYZ' some proportion
didn't realize I meant 'Don't argue unless you have new facts: do XYZ or
go away.'  This wastes my time, so I started being explicit.

But be gentle with people.  You've already called their baby ugly.

Cheers,
Rusty.

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Willy Tarreau]

On Mon, Jul 15, 2013 at 08:17:30PM -0400, Steven Rostedt wrote:
> On Mon, 2013-07-15 at 16:15 -0700, Guenter Roeck wrote:
> >  
> > One thing you should keep in mind in your discussion is what can happen
> > if people get too polite with each other.
> > 
> > I have seen this happen at two large companies I worked for. Early on, flames
> > are acceptable and expected as response to someone publishing bad code which
> > breaks everything for everyone. Then, at some point, it is not acceptable
> > anymore to flame, and one is expected to be polite and friendly at all times.
> > "Your code breaks the build for every platform. Would you please kindly
> > consider fixing it ?"
> > Result is that code quality suffers, to the point where images don't even
> > build anymore.
> > 
> > I hope the Linux kernel never gets into that stage. To avoid that,
> > I am willing to be cursed at by Linus if I am the responsible party.
> 
> Didn't Jim Zemlin show some research where there were two groups:
> 
>  One that did a bunch of brain storming where no idea was a bad idea
> 
>  The other required you to defend your idea while the others bashed it.
> 
> The results always showed that the second group not only did a better
> job, but also faster and more efficient.
> 
> I'm afraid if we worry too much about politeness, we will fall into that
> first group.

Linus already said you don't need to feer this change from him :-)

Willy

Re: [ 00/19] 3.10.1-stable review

[Willy Tarreau]

Hi Neil,

On Tue, Jul 16, 2013 at 08:40:36AM +1000, NeilBrown wrote:
> On Mon, 15 Jul 2013 21:17:27 +0200 Willy Tarreau <w@1wt.eu> wrote:
> 
> > Communication works two ways.
> 
> I understand that to mean (at least) that for communication, every message
> must be both sent and received.  So when constructing a message, it is
> important to think about how others will understand it.

Yes, and I'd say that "others" here is "most of the readers". I've been
using that in some large companies, sometimes people do wrong things and
defend themselves of stupid choices by putting tens of people in copy to
try to cover their ass.

This is where I please myself. I only assemble nice words that everyone
understands to build sentences that several readers will interprete with
a varying degree of aggressivity. The aggressivity is at its top for the
target, but non-existent for the most external readers. You end up with
a person justifying him/herself in public about something apparently not
existing, till the point where someone high asks "what are you talking
about, care to elaborate?". You get impressive results this way, wrong
projects being aborted, budgets to fix others. Not a single bad word,
yet it is an extermely unpleasant experience for the target who feels
naked in public and hates me. Quite frankly these persons would prefer
a single hard e-mail from Linus than a week long of chess game like this.
So yes, everyone's understanding is important.

> On a public email list there are an awful lot of "others", and it is very
> likely that any possible misunderstanding will be experienced by someone.
> I think it best to minimise opportunities for misunderstanding.

Yes exactly, especially for non-native readers who don't always
understand some cultural jokes. There were a number of non-important
jokes I didn't catch in this thread and that are not important. However
generally when Linus gives someone his "appreciation" for a given work,
there is very little room for misinterpretation, which is fine. He once
severely scolded me on the sec list for insisting on proposing a fix for
an issue I misunderstood. I had all the colorful details to understand
the issue and to realize that I was lacking some skills in the specific
area subject of the issue.

> > Sure it can be hard for newcomers but I don't remember having read him
> > scold a newcomer. 
> 
> I think that is not relevant.  He is scolding people senior developers in
> front of newcomers.  That is not likely to encourage people to want to become
> senior developers.

I'm not that sure, because instead newcomers think "this guy is a bastard, I
don't want to work with him, I'll work with maintainers instead". And that's
what is expected. They start by focusing on a given subsystem, and as years
pass, they realize that the guy with the big mouth is not that naughty,
especially when he helps them design or fix their work.

> Anecdote:  My son (in highschool) is doing a psych assignment where he is
> asking people to complete a survey which, among other things, asks about
> people fear/anxiety response to various situations (it is a fairly standard
> instrument I think[1]).  Last few times he checked, the situation with the
> highest average score was "One person bullying another".  Really, it isn't
> nice to watch.

That's an interesting study which very likely matches reality, but here
it's a bit different. The group of people is not just two guys having
words together, imagine a room with hundreds or thousands of people and
two in the middle fighting. They'll just get ignored by newcomers who
will preferably sit down close to people who discuss calmly.

I have another anecdote. A few years ago, one very discrete and respectful
developer used to help me with backports of some security fixes. At some
point I asked him "wouldn't you prefer to be on the sec list, it would be
easier", and he replied "Linus will never accept, he once scolded me in
public", and I replied "quite the opposite then, that's good for you".
And when I asked, Linus said "yes of course I want him on the list, he
can certainly help us". So as you see, if some people are impressed first,
they can still be brought in front of the one they fear and realize that
they were thinking wrong.

It can seem counter-producting first (as Sarah thinks) but I think that
the competent people find their way in this simply because they're backed
up by other ones. That's how I think we get that number of skilled people
at the top of each subsystem.

And last, from some feedback I got, I would suspect that some top developers
prefer one e-mail from Linus once in a while to countless e-mails from end
users who repeatedly criticize their work when something does not work like
they expect for whatever reasons (including PEBKAC).

Best regards,
Willy

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[David Lang]

On Mon, 15 Jul 2013, Sarah Sharp wrote:

> The people who want to work together in a civil manner should get
> together and create a "Kernel maintainer's code of conduct" that
> outlines what they expect from fellow kernel developers.  The people who
> want to continue acting "unprofessionally" should document what
> behaviors set off their cursing streaks, so that others can avoid that
> behavior.  Somewhere in the middle is the community behavior all
> developers can thrive in.

By defining your viewpoint as being "professional" and the other viewpoint as 
being "unprofessional" you have already started using very loaded terms and 
greatly reduces the probability of actually getting the other group to agree and 
participate.

As has been said elsewhere, almost all the attacks are against code, not people. 
There are occasional outbursts at the more experienced/trusted people along the 
lines of "you should know better than to do that", and while there is heat 
there, there is also a lot of truth. If those people can't be trusted not to do 
the wrong things, then we are back to the time when Linus had to review every 
patch himself and we hit that wall quite hard.

People do need to be called out on their mistakes. In companies, if you don't 
fire managers who do the wrong thing soon enough, it can ruin the company. In 
kernel development, you have a very large number of observers and if they don't 
see people being corrected for doing the wrong thing, they will emulate it.

I find that frequently the most educational discussions to read are the 'heated' 
ones, they are the ones where the 'right' and 'wrong' processes are most clearly 
explained, not just in terms of what the processes are, but also the WHY of the 
process being 'right' or 'wrong'.

If Linus just snaps at someone and they say 'oops, missed that', it's no big 
deal for anyone. But when a full argument/discussion takes place, a lot more 
people learn and apply the lessons to their own work.

David Lang

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Olivier Galibert]

On Tue, Jul 16, 2013 at 9:32 AM, David Lang <david@lang.hm> wrote:
> On Mon, 15 Jul 2013, Sarah Sharp wrote:
>
>> The people who want to work together in a civil manner should get
>> together and create a "Kernel maintainer's code of conduct" that
>> outlines what they expect from fellow kernel developers.  The people who
>> want to continue acting "unprofessionally" should document what
>> behaviors set off their cursing streaks, so that others can avoid that
>> behavior.  Somewhere in the middle is the community behavior all
>> developers can thrive in.
>
>
> By defining your viewpoint as being "professional" and the other viewpoint
> as being "unprofessional" you have already started using very loaded terms
> and greatly reduces the probability of actually getting the other group to
> agree and participate.

Especially since you can very easily translate these terms into
"American" and "non-American".

The stereotypical american professionalism attitude is to be polite at
the word choice level the best to hide a profund disrespect under
them.  There's no meaning taken into account, it's just keyword
spotting.  "Your code is crap" is considered unprofessional, while
"Let's leverage my fifth grade nephew's capabilities to assist you in
fixing the code" is perfectly professional, somehow.  That's more
often than not an unacceptable attitude in europe.

  OG.

Re: [ 00/19] 3.10.1-stable review

[Geert Uytterhoeven]

On Mon, Jul 15, 2013 at 10:41 PM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
> I should not have to ask for professional behavior on the mailing lists.
> Professional behavior should be the default.

So, what does "professional" mean? A professional is paid for his work, an
amateur isn't. But this doesn't say anything about code quality, maintainer
responsiveness, etc.
Does it imply behavior that (hopefully) keeps getting you paid?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [ 00/19] 3.10.1-stable review

[Alex Elder]

On 07/15/2013 02:07 PM, Linus Torvalds wrote:
> But when people who know better send me crap, I'll curse at them.
> 
> I suspect you'll notice me cursing *way* more at top developers than
> random people on the list. I expect more from them, and conversely
> I'll be a lot more upset when they do something that I really think
> was not great.

I have always found this to be the case.

Linus has high expectations, and I think the quality of
Linux code speaks volumes about the long-term effect of
that.  Blistering messages from Linus are directed at
people who have an established reputation, but who
present something less than high-caliber work.

Our communication is very open and public though.  Those
with some experience in the community should know that
these strongly-worded messages are not sent indiscriminately.
This isn't obvious to a newcomer though.  A stranger may
not realize that the shouting is among friends who care a lot
about what they're doing.

If the conversation weren't so public it may not seem
as inappropriate.  The shaming and flaming style is
effective for keeping top people in line.  But it does
needlessly intimidate new people in the process.

					-Alex

Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Tue, 2013-07-16 at 16:30 +0200, Geert Uytterhoeven wrote:
> On Mon, Jul 15, 2013 at 10:41 PM, Sarah Sharp
> <sarah.a.sharp@linux.intel.com> wrote:
> > I should not have to ask for professional behavior on the mailing lists.
> > Professional behavior should be the default.
> 
> So, what does "professional" mean? A professional is paid for his work, an
> amateur isn't. But this doesn't say anything about code quality, maintainer
> responsiveness, etc.
> Does it imply behavior that (hopefully) keeps getting you paid?
> 

Let me give you an example of a "professional" environment. When I use
to work for a large corporation, we had one guy doing some work for us
and he was rather new to our department (not new as a programmer). But I
swear, I have no idea how he became a programmer, and he's been with the
company for a while. He had to do a task that I was in charge of, and
gave him the requirements. He just couldn't understand it. I spent a
full week and a half "being nice" and going into details of what he
needed to do and he got no where. Finally, as I have now gone over every
aspect of what needed to be done and knew it in excruciating detail, I
sat down and wrote the entire thing myself in a single day. This was
something he was to do in two weeks.

When my manager heard about this, she blew up and sent a very nasty
email to the employee's manager, and things got really bad because of
the "nastiness" of the email and not the fact that we wasted two weeks
of being unproductive.

That's what a professional environment gives you, and honestly, I think
the Linux community can do without it.

-- Steve
 

Re: [ 00/19] 3.10.1-stable review

[Kees Cook]

On Tue, Jul 16, 2013 at 04:30:45PM +0200, Geert Uytterhoeven wrote:
> On Mon, Jul 15, 2013 at 10:41 PM, Sarah Sharp
> <sarah.a.sharp@linux.intel.com> wrote:
> > I should not have to ask for professional behavior on the mailing lists.
> > Professional behavior should be the default.
> 
> So, what does "professional" mean? A professional is paid for his work, an
> amateur isn't. But this doesn't say anything about code quality, maintainer
> responsiveness, etc.
> Does it imply behavior that (hopefully) keeps getting you paid?

I think we're getting hung up on this specific phrase. I've interpreted
this issue with lkml communication as a need to avoid bullying.  I think
"no bullying", while still up for heavy interpretation, is better to
focus on than "being professional".

-Kees

-- 
Kees Cook                                            @outflux.net

Re: [ 00/19] 3.10.1-stable review

[Darren Hart]

On Tue, 2013-07-16 at 08:09 -0700, Kees Cook wrote:
> On Tue, Jul 16, 2013 at 04:30:45PM +0200, Geert Uytterhoeven wrote:
> > On Mon, Jul 15, 2013 at 10:41 PM, Sarah Sharp
> > <sarah.a.sharp@linux.intel.com> wrote:
> > > I should not have to ask for professional behavior on the mailing lists.
> > > Professional behavior should be the default.
> > 
> > So, what does "professional" mean? A professional is paid for his work, an
> > amateur isn't. But this doesn't say anything about code quality, maintainer
> > responsiveness, etc.
> > Does it imply behavior that (hopefully) keeps getting you paid?
> 
> I think we're getting hung up on this specific phrase. I've interpreted
> this issue with lkml communication as a need to avoid bullying.  I think
> "no bullying", while still up for heavy interpretation, is better to
> focus on than "being professional".
> 

Agreed. The swearing will continue until code quality improves.

The bit I can get behind is the avoidance of personal attacks. Some on
this thread have argued that instances of such attacks are now few and
far between. Is that the case? How many are we talking about? 10/day?
10/year? Is it truly only the lieutenants getting public lashings?

I understand that it is the environment itself, the accepted norms, the
"standard you walk past" (as Sarah has quoted) that is the real focus.
So yes, let's not get hung up on professional/unprofessional or any
other such subjective term or fall into the PC traps.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: [ 00/19] 3.10.1-stable review

[Darren Hart]

On Tue, 2013-07-16 at 08:13 +0200, Willy Tarreau wrote:

> It can seem counter-producting first (as Sarah thinks) but I think that
> the competent people find their way in this simply because they're backed
> up by other ones. That's how I think we get that number of skilled people
> at the top of each subsystem.
> 

Hi Will,

I think you've made some excellent points and have done a good job
relating the mostly digital interactions to more direct and tangible
ones.

You have postulated (I believe) that because we have top-quality
maintainers (and I agree, we do), the process must be working. Perhaps
that was my interpretation and not your intent, but others have voiced
such opinions as well, so the following is still relevant.

What that argument fails to take into account are the top-quality
maintainers and contributors who are not present because of the
sometimes caustic environment of Linux kernel development: "survivor's
bias". There is a great article on the subject I read recently here:

http://youarenotsosmart.com/2013/05/23/survivorship-bias/


-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: [ATTEND] How to act on LKML

[Stefano Stabellini]

On Mon, 15 Jul 2013, H. Peter Anvin wrote:
> On 07/15/2013 08:06 PM, Steven Rostedt wrote:
> > 
> > Linus's point is that he wants to be honest, and cursing is his way of
> > giving you the most direct way to understand how he honestly feels.
> > 
> 
> What I don't get about anything of this is that I have always found
> Linus' being hyper-obviously over the top sarcastic when he goes on a
> rant.  There is usually plenty of context to derive that from, too, even
> if you haven't seen him in person enough to virtually hear the smirk in
> his voice.  This is a form of humor more than anything else, and at
> least I find it utterly impossible to be offended by it.  As the main
> target of the rant this weekend, I (a) chuckled, and (b) said "I think I
> need to do some damage control".

I agree with Sarah.

I have been hacking in several different Open Source communities during
the last few years, including qemu-devel, xen-devel, linux-arm and the
lkml of course.

The etiquette on the lkml is by far the roughest of them all. It's the
"bad neighborhood with guns" of the Open Source world. You never know
when you are going to get a bullet, but sooner or later you'll get one.

I think that it's hurting Linux and in particular it's hurting
attracting new talents.  Not just devs for hire but people passionate
about what they do and eager to become more involved in the project.
I met more than one good ex-Linux hacker that decided to move to do
other things because of this.

Re: [ATTEND] How to act on LKML

[Steven Rostedt]

On Tue, 2013-07-16 at 16:49 +0100, Stefano Stabellini wrote:

> I have been hacking in several different Open Source communities during
> the last few years, including qemu-devel, xen-devel, linux-arm and the
> lkml of course.
> 
> The etiquette on the lkml is by far the roughest of them all. It's the

It's also the largest of them all.

> "bad neighborhood with guns" of the Open Source world. You never know
> when you are going to get a bullet, but sooner or later you'll get one.

It just seems that way as it is so large. LKML has the most people and
will also have the biggest conflict in personalities. It just goes with
the territory.

> 
> I think that it's hurting Linux and in particular it's hurting
> attracting new talents.

Then why do we have the largest # of developers than any other Open
Source project?


>   Not just devs for hire but people passionate
> about what they do and eager to become more involved in the project.
> I met more than one good ex-Linux hacker that decided to move to do
> other things because of this.

Honestly, I think LKML over the years has become more tame. Yeah, back
in 2005 it was rather harsh, but I don't really see that anymore. I
don't see the nasty flame wars going on. Everything seems to be focused
more on the technical side, and there's really very little personal
attacks out there. Sure, with 15,000 emails a month, you get a few. And
Linus will get fed up and burst. But they are really few and far
between. And sometimes, a Linus burst gets things moving along much
faster than being "professional". You think ARM would have gotten their
act together as quick as they did if Linus didn't curse them out and
threaten to stop pulling their crap?

-- Steve

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[David Howells]

Linus Torvalds <torvalds@linux-foundation.org> wrote:

> A small panel discussion with a few people (fiveish?) that have very
> different viewpoints, along with baskets of rotten fruit set out on
> the tables? That could be fun. And I'm serious, although we might want
> to limit the size of the fruit to smaller berries ;)

I think that smuggling one of these:

	http://www.kropserkel.com/horse_head_pillow.htm

into Linus's bed might make the point;-).

David

Re: [ATTEND] How to act on LKML

[Stefano Stabellini]

On Tue, 16 Jul 2013, Steven Rostedt wrote:
> On Tue, 2013-07-16 at 16:49 +0100, Stefano Stabellini wrote:
> 
> > I have been hacking in several different Open Source communities during
> > the last few years, including qemu-devel, xen-devel, linux-arm and the
> > lkml of course.
> > 
> > The etiquette on the lkml is by far the roughest of them all. It's the
> 
> It's also the largest of them all.
> 
> > "bad neighborhood with guns" of the Open Source world. You never know
> > when you are going to get a bullet, but sooner or later you'll get one.
> 
> It just seems that way as it is so large. LKML has the most people and
> will also have the biggest conflict in personalities. It just goes with
> the territory.

Even though the LKML is probably the largest Open Source community,
there are other groups out there of similar size.
I don't believe that in order to scale up we need to be like this.


> > I think that it's hurting Linux and in particular it's hurting
> > attracting new talents.
> 
> Then why do we have the largest # of developers than any other Open
> Source project?

Because Linux is the most widely used kernel, it's everywhere from
embedded devices to supercomputers.
Many different companies make a business on Linux and pay people to work
on it (not FreeBSD or NetBSD). But that's different from what I was
saying below. Also not all the sub-groups within the kernel development
circles work this way.

Or maybe there are just enough brilliant kernel developers that don't
care.


> >   Not just devs for hire but people passionate
> > about what they do and eager to become more involved in the project.
> > I met more than one good ex-Linux hacker that decided to move to do
> > other things because of this.
> 
> Honestly, I think LKML over the years has become more tame. Yeah, back
> in 2005 it was rather harsh, but I don't really see that anymore. I
> don't see the nasty flame wars going on. Everything seems to be focused
> more on the technical side, and there's really very little personal
> attacks out there. Sure, with 15,000 emails a month, you get a few. And
> Linus will get fed up and burst. But they are really few and far
> between. And sometimes, a Linus burst gets things moving along much
> faster than being "professional". You think ARM would have gotten their
> act together as quick as they did if Linus didn't curse them out and
> threaten to stop pulling their crap?
 
I think there is a way to get the point across without cursing.
One can be clear and decisive without "bursting". It's easy to mistake
cursing on the quality of the code for a personal attack.

When HPA wrote "I find it utterly impossible to be offended by it", that
might be true for Linus' rants and I also find them humorous sometimes.
But unfortunately this kind of behavior is by no means limited to Linus
and it's easy to misunderstand, especially when you don't know the
person.

Re: [ATTEND] How to act on LKML

[Steven Rostedt]

On Tue, 2013-07-16 at 17:58 +0100, Stefano Stabellini wrote:
>  
> I think there is a way to get the point across without cursing.
> One can be clear and decisive without "bursting". It's easy to mistake
> cursing on the quality of the code for a personal attack.

What's wrong with cursing? It's just words. The more you curse, the less
effect it has. I seldom curse, but when I do, people jump and listen.
That's because I seldom curse.

I have two teenage daughters. I've never heard them curse at all, and
I'm not sure my oldest ever has. From a young age, I taught them that I
don't care what they hear, it's what they say that counts. I never
sheltered them from "curse" words. I taught them that curse words are
for when you really need to make a point and want everyone to listen to
you because you are really upset. The less you use them, the more impact
they have when you do. They took this to heart, and are saving it up for
when something big happens, because I can't get them to curse even when
I try :-)

-- Steve

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Guenter Roeck]

On Tue, Jul 16, 2013 at 12:32:53AM -0700, David Lang wrote:
> On Mon, 15 Jul 2013, Sarah Sharp wrote:
> 
> People do need to be called out on their mistakes. In companies, if
> you don't fire managers who do the wrong thing soon enough, it can
> ruin the company. In kernel development, you have a very large
> number of observers and if they don't see people being corrected for
> doing the wrong thing, they will emulate it.
> 
And I have seen that happen way too often :(.

Guenter

Re: [ 00/19] 3.10.1-stable review

[Willy Tarreau]

Hi Darren,

On Tue, Jul 16, 2013 at 08:40:15AM -0700, Darren Hart wrote:
> On Tue, 2013-07-16 at 08:13 +0200, Willy Tarreau wrote:
> 
> > It can seem counter-producting first (as Sarah thinks) but I think that
> > the competent people find their way in this simply because they're backed
> > up by other ones. That's how I think we get that number of skilled people
> > at the top of each subsystem.
> > 
> 
> Hi Will,
> 
> I think you've made some excellent points and have done a good job
> relating the mostly digital interactions to more direct and tangible
> ones.
> 
> You have postulated (I believe) that because we have top-quality
> maintainers (and I agree, we do), the process must be working. Perhaps
> that was my interpretation and not your intent, but others have voiced
> such opinions as well, so the following is still relevant.
> 
> What that argument fails to take into account are the top-quality
> maintainers and contributors who are not present because of the
> sometimes caustic environment of Linux kernel development: "survivor's
> bias".

No, I'm not forgetting this, and I'm sure this is a fact. We don't have
that many shy people here I think. But the question would probably better
be "are the efforts and implications of adopting a softer communication
worth the gain of getting a few more talented people ?". I don't have the
response to this question, but for sure many things would change, some
current developers would not follow, release cycles would extend, but
maybe we'd get a slightly higher quality each time, who knows. Also, too
shy people rarely propose improvements, even if they tend to have the
greatest ideas since they spend more time thinking than talking. What I'm
sure about however is that the two models are incompatible, and breaking
one which works to try another one seems suicidal. And Linus would probably
suggest "try it, fork the kernel, build a team and manage it your way".

All in all, I think the best thing to do would be to improve the processes
so that it becomes much clearer for everyone so that newcomers are less
afraid of it and do less mistakes. With a smoother process we can expect
a higher quality from everyone and in turn reduce the risk that Linus
shouts too often. Everyone will benefit from this in the end. I'm not
the best placed to propose improvements, I'm not suffering from the
process, so let's hope that people who are unhappy with it will explain
their concerns in great details.

> There is a great article on the subject I read recently here:
> 
> http://youarenotsosmart.com/2013/05/23/survivorship-bias/

Seems interesting but very long, I'll have to read it later ! Thanks for
the link anyway.

Willy

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[James Bottomley]

On Mon, 2013-07-15 at 15:38 -0700, Linus Torvalds wrote:
> On Mon, Jul 15, 2013 at 3:08 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > Can we please make this into a Kernel Summit discussion. I highly doubt
> > we would solve anything, but it certainly would be a fun segment to
> > watch :-)
> 
> I think we should, because I think it's the kind of thing we really
> need at the KS - talking about "process".

Can you formulate the process issue to discuss?  I've heard "Linus needs
to yell less at people" and "the mailing lists need to be more
'professional'" neither of which seems to identify an actual process.
Are we perhaps discussing guidelines for giving feedback on patches?

> At the same time, I really don't know what the format would possibly
> be like for it to really work as a reasonable discussion. And I think
> that is important, because this kind of subject is *not* likely
> possible in the traditional "people sit around tables and maybe
> somebody has a few slides" format.

> A small panel discussion with a few people (fiveish?) that have very
> different viewpoints, along with baskets of rotten fruit set out on
> the tables? That could be fun. And I'm serious, although we might want
> to limit the size of the fruit to smaller berries ;)

How about Lychees?  They're prickly on the outside, very wet on the
inside and have large stones ...

But what are the viewpoints?  "maintainers need to yell more"?
"maintainers need to yell less"?  I don't think I agree with either.
I'm perfectly happy to run linux-scsi along reasonable standards of
civility and try to keep the debates technical, but that's far easier to
do on a low traffic list; obviously, I realise that style of argument
doesn't suit everyone, so it's not a standard of behaviour I'd like to
see universally imposed.  In fact, I've got to say that I wouldn't like
to see *any* behaviour standard imposed ... they're all basically cover
for power plays (or soon get abused as power plays); the only real way
to display leadership on behaviour standards is by example not by fiat.

James

Re: [ATTEND] How to act on LKML

[H. Peter Anvin]

On 07/16/2013 09:58 AM, Stefano Stabellini wrote:
> 
> Because Linux is the most widely used kernel, it's everywhere from
> embedded devices to supercomputers.
> Many different companies make a business on Linux and pay people to work
> on it (not FreeBSD or NetBSD). But that's different from what I was
> saying below. Also not all the sub-groups within the kernel development
> circles work this way.
> 

I think you have an inverse causal relationship here.

Linux took off in a way that the other OSS operating systems didn't, and
several of them had started earlier and with way more funding available.

You really have to think about why we are not running Hurd, or any of
the various *BSDs, and instead Linus' "not big and professional like
GNU" hack.  In my opinion it was because the Linux community was in fact
the most open and welcoming of the Open Source communities around.

> When HPA wrote "I find it utterly impossible to be offended by it", that
> might be true for Linus' rants and I also find them humorous sometimes.
> But unfortunately this kind of behavior is by no means limited to Linus
> and it's easy to misunderstand, especially when you don't know the
> person.

There seem to be a fair number of people who think they can imitate
Linus' style but do so without understanding the subtle aspects about
how to apply it.

	-hpa

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Martin Steigerwald]

Am Montag, 15. Juli 2013, 15:50:03 schrieb Sarah Sharp:
> On Mon, Jul 15, 2013 at 03:38:42PM -0700, Linus Torvalds wrote:
> > On Mon, Jul 15, 2013 at 3:08 PM, Steven Rostedt <rostedt@goodmis.org> 
> > wrote:
> > > Can we please make this into a Kernel Summit discussion. I highly doubt
> > > we would solve anything, but it certainly would be a fun segment to
> > > watch :-)
> > 
> > I think we should, because I think it's the kind of thing we really
> > need at the KS - talking about "process".
> > 
> > At the same time, I really don't know what the format would possibly
> > be like for it to really work as a reasonable discussion. And I think
> > that is important, because this kind of subject is *not* likely
> > possible in the traditional "people sit around tables and maybe
> > somebody has a few slides" format.
> > 
> > A small panel discussion with a few people (fiveish?) that have very
> > different viewpoints, along with baskets of rotten fruit set out on
> > the tables? That could be fun. And I'm serious, although we might want
> > to limit the size of the fruit to smaller berries ;)
> > 
> > Sarah will bring the brownies.
> 
> Peace pot brownies!  I love it!

I wish you good luck for that KS session!

As someone who brought up this topic before¹ I applaud for your courage to 
raise this as a kernel developer, Sarah. I took way less risk cause my only 
direct contribution to the kernel was a documentation patch in 2.6.28 and thus 
I have much less too loose. And Ingo treated me absolutely professionally back 
then. (You will find my name more often in changelog, regarding bug reporting 
and testing of fixes which is also an important activity I think.)

I didn´t think much about it since I brought up the topic and didn´t even yet 
search for studies that cursing is healthy as Linus suggested to me… partly 
due to putting focus to other more important topics in my life and partly 
possibly due to the thought that its just me having a problem with some of the 
tone on this list after having got the reactions I got in that thread.

I share some random thoughts for you, Linus and others, use them or leave them 
aside as you wish:

- I think that it is possible to a) clearly express one´s own oppinion and get 
a across the point and b) clearly make it obvious that this is about the 
matter at hand and no attack of the person on the receiving side of the 
feedback. Actually I do think this is just a plain simple communication 
*skill*, thus learnable. Well I studied something like this. I can share some 
key points of non-violent but still bringing across the point way of 
communicating if interested.

- I am with Linus in that its important to express own emotions before at 
times. And heck I saw you expressing your emotions here in this thread as 
well. There is never anything wrong with expressing a emotion as there is 
never anything wrong with the emotion as it is. But I do think its important 
to clearly do it as an *own* emotion. A emotion I have has to do with one 
person: Myself. It might be a reaction to a thought I have, maybe as a 
reaction to a feedback I got, buts it totally I am who is feeling that emotion 
and I am always in charge. Thus I have absolutely no issue with "I am totally 
feed up with this and this" or "I am really angry at this and this happening 
just again after having it explained here and there". But a comment like "you 
suck cause you did this" and "its your fault" is not okay for me. I am 
changing my behavior from avoiding these situations altogether to have it not 
happen to me – which is a typical pattern of people feeling abused and not 
guarenteed to work out – to expressing that it is so for me. And even more 
importantly to accept me as a person no matter whether Linus would be calling 
me names or what not as this helps me to get the courage to stand for myself. 
However at times I am still reluctant to post here for fear of getting 
attacked personally.

- I did read quite some of Linus posts, also angrier ones, and on a closer 
look I see that many of them do *not* contain a personal attack. I agree with 
some here that calling certain code crap *with* providing a reason for this 
actually is beneficial. And I think that if that is a personal attack for 
someone it is so cause the person identifies with her or his code. 
Understandable, but it is the problem of that person just as if Linus has a 
problem with a patch or a change it is *his* problem to deal with.

- I do think that a person won´t change cause I want him or her to change. 
Thus I think that Linus won´t change until he really wants to, Sarah, and I 
see absolutely no way how you can change him. Or vice versa. I can only ever 
change myself. Actually I think I did already. I trained myself to look more 
carefully at language which helped me to see that quite some of Linus language 
does not contain attacks against a person, but against the code. And I allowed 
myself to express my concerns about tone in this list *regardless* of the 
feedback that I may get. And I assured that I will stand for myself, no matter 
what others do to me. (Actually I still do not buy into the bad guy role that 
Linus plays at times. This I did not change.)

- Lastly I think I would be careful with the term abuse. For me an abuse 
implies that the abused is not able to avoid the treatment. Which may easily 
the case for a child being abused. Or for a woman who has less physical 
strength (and no experience with martial arts) than an abusive man. But as a 
grown up person posting and reading in a mailing list its always my own 
decision whether I buy into what I perceive as verbal attack *or not*. Whether 
I stand up and say "I am not taking this" or just take it in and hurt myself 
by doing it. How I react to something I receive is solely at my disposal. So I 
really enjoyed your "I won´t take this" to Linus.


So I think this is not about *changing* people. But I do think its important 
that a kernel developer like you spoke up and raised issues with the tone in 
this list.

So I end with a suggestion for the Kernel Summit discussion, take it or leave 
it:

As a first step let each one just express how he or she feels about this topic 
and what she or he expects to be treated as. And then as a first challenge just 
let these likely highly different view points stand beside each other and work 
from there.


PS: In my Linux trainings when I talk about that still most kernel developers 
are male I usually mention your USB 3 stack contribution as a notable example 
of a work by a female developer.


[1] Re: Linux 3.10-rc6, 16 Jun 2013:
https://lkml.org/lkml/2013/6/16/77

Regards,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Re: [ 00/19] 3.10.1-stable review

[Sarah Sharp]

On Tue, Jul 16, 2013 at 02:22:14PM +0930, Rusty Russell wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
> > On Mon, Jul 15, 2013 at 12:17 PM, Willy Tarreau <w@1wt.eu> wrote:
> >>
> >> BTW, I was amazed that you managed to get him have a much softer tone inr
> >> his last e-mail, you probably found a weakness here in his management
> >> process :-)
> >
> > Hey, I _like_ arguing, and "cursing" and "arguing" are actually not at
> > all the same thing.
> >
> > And I really don't tend to curse unless people are doing something
> > stupid and annoying. If people have concerns and questions that I feel
> > are valid, I'm more than happy to talk about it.
> >
> > I curse when there isn't any argument. The cursing happens for the
> > "you're so f*cking wrong that it's not even worth trying to make
> > logical arguments about it, because you have no possible excuse" case.
> >
> > .. and sometimes people surprise me and come back with a valid excuse
> > after all. "My whole family died in a tragic freak accident and my
> > pony got cancer, and I was distracted".
> >
> > And then I might even tell them I'm sorry.
> >
> > No. Not really.
> 
> You have to be harsh with code: People mistake politeness for
> uncertainty.  Whenever I said 'I prefer if you XYZ' some proportion
> didn't realize I meant 'Don't argue unless you have new facts: do XYZ or
> go away.'  This wastes my time, so I started being explicit.
> 
> But be gentle with people.  You've already called their baby ugly.

Rusty hit the nail on the head here.  I want everyone (including Linus)
to be harsh with code but gentle with people.

I personally don't care if emails are peppered with a little cussing.
You can see I've included some words like "fuck" in my emails too.
However, I object to how the cursing is *directed*.

In the x86 email [1], you could argue that Linus' tone was pretty
grumpy, maybe even abrasive.  However, he was criticizing *code* when he
cursed:


"This piece-of-shit commit is marked for stable, but you clearly never
even test-compiled it, did you?"

"I made the mistake of doing multiple merges back-to-back with the
intention of not doing a full allmodconfig build in between them, and
now I have to undo them all because this pull request was full of
unbelievable shit."

"And why the hell was this marked for stable even *IF* it hadn't been
complete and utter tripe? It even has a comment in the commit message
about how this probably doesn't matter."


Linus is complaining about code here, and the effects of merging bad
code on his own tree.  I personally have no qualms with this type of
harsh email, because it focuses on the code, not the person.

I do, however, object when the verbal abuse shifts from being directed
at code to being directed at *people*.  For example, Linus chose to
curse at Mauro [2] and Rafael [3], rather than their code:


"Mauro, SHUT THE FUCK UP!"

"How long have you been a maintainer? And you *still* haven't learnt the
first rule of kernel maintenance?"

"Shut up, Mauro. And I don't _ever_ want to hear that kind of obvious
garbage and idiocy from a kernel maintainer again. Seriously."

"The fact that you then try to make *excuses* for breaking user space,
and blaming some external program that *used* to work, is just
shameful. It's not how we work."

"Fix your f*cking "compliance tool", because it is obviously broken.
And fix your approach to kernel programming."

"Seriously. Why do I even have to mention this? Why do I have to
explain this to somebody pretty much *every* f*cking merge window?"

"And btw, the *reason* for that rule becoming such a hard rule was
pretty much exactly suspend/resume and ACPI. Exactly because we used
to have those infinite "let's fix one thing and break another" dances.
So you should be well acquainted with the rule, and I'm surprised to
hear that kind of utter garbage from you in particular."


The personally directed verbal abuse is what I'm complaining about here.
Linus goes from 0 to 11 at the drop of an "I don't think this is a
regression" comment, and publicly ridicules his top maintainers.

This is not right.  This is not a community that people want to be a
part of, except for a few top-tier maintainers who have "tough skins".
No one should have to be the focus of a fire hose of personal verbal
abuse.

We're adults, not high schoolers.  We can figure out how to deliver
harsh technical criticism without resorting to name calling, cussing at
people, or personal attacks.

If a maintainer is not doing their job, Linus should send them a private
harsh email, and a public email that simply says, "I'm reverting this
pull request because of X.  If this continues through the next merge
window, this maintainer will need to train a replacement."  Don't
publicly tear them to pieces because they made a simple mistake.


The definition of insanity is repeating the same thing, over and over,
expecting the result to be different.  Linus keeps repeating the same
mantras over and over to maintainers that forget rules like, "No
regressions."

Why aren't we trying different tactics?  Why aren't we improving our
documentation so maintainers don't have to repeat themselves?

Sarah Sharp

[1] https://lkml.org/lkml/2013/7/13/132
[2] http://marc.info/?l=linux-kernel&m=135628421403144&w=2
[3] http://marc.info/?l=linux-acpi&m=136157944603147&w=2

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Sarah Sharp]

On Tue, Jul 16, 2013 at 11:14:51AM +0200, Olivier Galibert wrote:
> On Tue, Jul 16, 2013 at 9:32 AM, David Lang <david@lang.hm> wrote:
> > On Mon, 15 Jul 2013, Sarah Sharp wrote:
> >
> >> The people who want to work together in a civil manner should get
> >> together and create a "Kernel maintainer's code of conduct" that
> >> outlines what they expect from fellow kernel developers.  The people who
> >> want to continue acting "unprofessionally" should document what
> >> behaviors set off their cursing streaks, so that others can avoid that
> >> behavior.  Somewhere in the middle is the community behavior all
> >> developers can thrive in.
> >
> >
> > By defining your viewpoint as being "professional" and the other viewpoint
> > as being "unprofessional" you have already started using very loaded terms
> > and greatly reduces the probability of actually getting the other group to
> > agree and participate.
> 
> Especially since you can very easily translate these terms into
> "American" and "non-American".
> 
> The stereotypical american professionalism attitude is to be polite at
> the word choice level the best to hide a profund disrespect under
> them.  There's no meaning taken into account, it's just keyword
> spotting.  "Your code is crap" is considered unprofessional, while
> "Let's leverage my fifth grade nephew's capabilities to assist you in
> fixing the code" is perfectly professional, somehow.  That's more
> often than not an unacceptable attitude in europe.

I *hate* both direct personal insults and indirect personal insults.
Neither should be acceptable in our community.

As I stated in an email to Rusty, what I'm objecting to here is not
kernel developers criticizing code.  I'm objecting to personal attacks,
and developers directing personal verbal abuse towards each other.  This
include all developers, not just Linus.

Sarah Sharp

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Paul E. McKenney]

On Tue, Jul 16, 2013 at 10:27:09PM +0400, James Bottomley wrote:
> On Mon, 2013-07-15 at 15:38 -0700, Linus Torvalds wrote:
> > On Mon, Jul 15, 2013 at 3:08 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > >
> > > Can we please make this into a Kernel Summit discussion. I highly doubt
> > > we would solve anything, but it certainly would be a fun segment to
> > > watch :-)
> > 
> > I think we should, because I think it's the kind of thing we really
> > need at the KS - talking about "process".
> 
> Can you formulate the process issue to discuss?  I've heard "Linus needs
> to yell less at people" and "the mailing lists need to be more
> 'professional'" neither of which seems to identify an actual process.
> Are we perhaps discussing guidelines for giving feedback on patches?
> 
> > At the same time, I really don't know what the format would possibly
> > be like for it to really work as a reasonable discussion. And I think
> > that is important, because this kind of subject is *not* likely
> > possible in the traditional "people sit around tables and maybe
> > somebody has a few slides" format.
> 
> > A small panel discussion with a few people (fiveish?) that have very
> > different viewpoints, along with baskets of rotten fruit set out on
> > the tables? That could be fun. And I'm serious, although we might want
> > to limit the size of the fruit to smaller berries ;)
> 
> How about Lychees?  They're prickly on the outside, very wet on the
> inside and have large stones ...

They taste good, too.

> But what are the viewpoints?  "maintainers need to yell more"?
> "maintainers need to yell less"?  I don't think I agree with either.
> I'm perfectly happy to run linux-scsi along reasonable standards of
> civility and try to keep the debates technical, but that's far easier to
> do on a low traffic list; obviously, I realise that style of argument
> doesn't suit everyone, so it's not a standard of behaviour I'd like to
> see universally imposed.  In fact, I've got to say that I wouldn't like
> to see *any* behaviour standard imposed ... they're all basically cover
> for power plays (or soon get abused as power plays); the only real way
> to display leadership on behaviour standards is by example not by fiat.

OK, I am stupid enough to take a stab at this...

1.	Does the Linux kernel community's health depend on the occasional
	rant?  [My guess is that we simply have no way of knowing.
	That said, I would be interested in hearing specific examples
	of open-source communities that are as doing as well as is the
	Linux community and that live within stricter social mores.
	Cue arguments about exactly what "doing well" means...]

2.	Could the Linux kernel community's health be improved by banning
	the occasional rant?  [Again, I don't believe that we have any
	way of knowing.]

3.	Is there some reasonable way to accommodate a wide range of
	styles of interaction within the Linux community?  [I hope that
	the answer is "yes", but it probably becomes impossible if you
	add the qualifier "that everyone is happy with".]

4.	If there is some reasonable way to accommodate a wide range
	of styles of interaction within the Linux community, can this
	be done globally, or does this require that people who prefer a
	specific style confine themselves to portions of the community
	that practice that specific style?  [As I grow older, I become
	increasingly pessimistic about the possibility of keeping everyone
	happy, but who knows?]

For whatever it is worth...

							Thanx, Paul

> James
> 
> 
> _______________________________________________
> Ksummit-2013-discuss mailing list
> Ksummit-2013-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-2013-discuss
> 

Re: [ 00/19] 3.10.1-stable review

[Linus Torvalds]

On Tue, Jul 16, 2013 at 2:08 PM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
>
> I do, however, object when the verbal abuse shifts from being directed
> at code to being directed at *people*.  For example, Linus chose to
> curse at Mauro [2] and Rafael [3], rather than their code:

Umm. Because it was actually the person who was the problem?

Trust me, there's a really easy way for me to curse at people: if you
are a maintainer, and you make excuses for your bugs rather than
trying to fix them, I will curse at *YOU*.

Because then the problem really is you.

And in *both* of the examples you cite, that was exactly the issue. It
wasn't that there was a bug - it was that the maintainer in question
basically refused to fix a regression.

Sure, there was a code problem. But that wasn't the big issue. Code
can be broken, and can be utter crap, but as long as it's fixed, who
cares?

But when top-level maintainers start ignoring the #1 rule in the
kernel ("We don't regress user space"), then it's not the broken code
that annoys me any more.

See the difference?

And yes, people who don't get this are people who I will literally
refuse to work with. In both of the cases you cite, things resolved
themselves quickly (in fact, with Rafael it was at least partially
just bad communication, and I haven't had that issue with him before).
Other people, who seem to treat regressions cavalierly, I will first
make it *very* clear that it is unacceptable, and then I will refuse
to take their patches. It has happened.

And yes, if that's the reason some person doesn't like working with
the kernel ("Linus screams at me when I break things and don't want to
fix them"), then dammit, good f*cking riddance. I already saw exactly
that comment on G+ earlier today - somebody who is well-known for not
fixing his regressions ("fix your user instead") was talking about how
he doesn't want to work with me for that very reason.

So apparently my cursing works.

Seriously, Sarah, you need to get off this "you can't curse at
people". Because you *can* curse at people, and it very much is
sometimes called for.

               Linus

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Theodore Ts'o]

On Tue, Jul 16, 2013 at 02:12:35PM -0700, Sarah Sharp wrote:
> "Your code is crap" is considered unprofessional, while
> > "Let's leverage my fifth grade nephew's capabilities to assist you in
> > fixing the code" is perfectly professional, somehow.  That's more
> > often than not an unacceptable attitude in europe.
> 
> I *hate* both direct personal insults and indirect personal insults.
> Neither should be acceptable in our community.

What is a "direct personal insult" can be in the eye of the beholder.
Personally, I don't consider "your code is crap" as a personal insult.
"You are an incompetent programmer for producing this crap" would be a
personal attack.

Similarly, there is a difference between "That was an idiotic idea"
and "You are an idiot".

Now, there are certainly more {diplomatic, politically correct,
choose-your-own-favorite-adjective} ways wording the description of a
particularly bad idea or piece of code.  But is that a "personal
attack"?

Keep in mind that there are some cultures where even pointing out a
technical flaw in code might considered bringing deep shame on the
engineer and their company.  So how sensitive people are to criticism
during an electronic exchange is always going to be highly culutrally
and personally variable.

   	  	      	     		- Ted

Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Tue, 2013-07-16 at 14:08 -0700, Sarah Sharp wrote:

> 
> "Mauro, SHUT THE FUCK UP!"
> 
> "How long have you been a maintainer? And you *still* haven't learnt the
> first rule of kernel maintenance?"
> 
> "Shut up, Mauro. And I don't _ever_ want to hear that kind of obvious
> garbage and idiocy from a kernel maintainer again. Seriously."
> 
> "The fact that you then try to make *excuses* for breaking user space,
> and blaming some external program that *used* to work, is just
> shameful. It's not how we work."
> 
> "Fix your f*cking "compliance tool", because it is obviously broken.
> And fix your approach to kernel programming."
> 
> "Seriously. Why do I even have to mention this? Why do I have to
> explain this to somebody pretty much *every* f*cking merge window?"
> 
> "And btw, the *reason* for that rule becoming such a hard rule was
> pretty much exactly suspend/resume and ACPI. Exactly because we used
> to have those infinite "let's fix one thing and break another" dances.
> So you should be well acquainted with the rule, and I'm surprised to
> hear that kind of utter garbage from you in particular."

Reading all this again, it seems that Linus is pissed off at what Mauro
said, did or is doing. I don't really see a direct attack at Mauro as a
person. Not much different than being pissed off at someone asking Linus
to pull crap that's marked for stable. I see a very fine line between
the two.

Also, it seems that Linus is more disappointed with Mauro, as he expects
more from him.

Honestly, sometimes Linus needs to yell louder to top maintainers. As
its a way to wake us up that we need to be held to a higher regard.
Sometimes we may get complacent, and a bit lazy. If a top maintainer
starts to slack, major damage can be done. It needs to be serious.

I don't see the above as public shaming. It really just points out what
Linus expects from all maintainers, which would have been lost if this
were a private email.


> 
> 
> The personally directed verbal abuse is what I'm complaining about here.
> Linus goes from 0 to 11 at the drop of an "I don't think this is a
> regression" comment, and publicly ridicules his top maintainers.
> 
> This is not right.  This is not a community that people want to be a
> part of, except for a few top-tier maintainers who have "tough skins".
> No one should have to be the focus of a fire hose of personal verbal
> abuse.

I still don't see it as personal. Linus got pissed at what Mauro said
and did, not at Mauro as a person. Thus, not personal.

"I'm surprised to hear that kind of utter garbage from you in
particular"

I actually read the above as a complement.

> 
> We're adults, not high schoolers.  We can figure out how to deliver
> harsh technical criticism without resorting to name calling, cussing at
> people, or personal attacks.

Was there name calling in the above? I missed it.

> 
> If a maintainer is not doing their job, Linus should send them a private
> harsh email, and a public email that simply says, "I'm reverting this
> pull request because of X.  If this continues through the next merge
> window, this maintainer will need to train a replacement."  Don't
> publicly tear them to pieces because they made a simple mistake.

That kind of email will most likely be ignored by people. A harsh email
becomes popular and noticed by a larger audience.

> 
> 
> The definition of insanity is repeating the same thing, over and over,
> expecting the result to be different.  Linus keeps repeating the same
> mantras over and over to maintainers that forget rules like, "No
> regressions."

No, I think people have heard this. And sometimes we start to think:
well this one may be different. Seems that its the maintainers that try
to do the same thing over and over expecting a different result from
Linus which is what makes Linus insane.


> 
> Why aren't we trying different tactics?  Why aren't we improving our
> documentation so maintainers don't have to repeat themselves?

There's lots of documentation, and I think its more that maintainers
thinking "this time it's different" than anything else. I guarantee that
Mauro will not push userspace breakage again. And because of that email,
so will a lot of other maintainers.

-- Steve

Re: [ 00/19] 3.10.1-stable review

[Rafael J. Wysocki]

On Tuesday, July 16, 2013 02:23:46 PM Linus Torvalds wrote:
> On Tue, Jul 16, 2013 at 2:08 PM, Sarah Sharp
> <sarah.a.sharp@linux.intel.com> wrote:
> >
> > I do, however, object when the verbal abuse shifts from being directed
> > at code to being directed at *people*.  For example, Linus chose to
> > curse at Mauro [2] and Rafael [3], rather than their code:
> 
> Umm. Because it was actually the person who was the problem?
> 
> Trust me, there's a really easy way for me to curse at people: if you
> are a maintainer, and you make excuses for your bugs rather than
> trying to fix them, I will curse at *YOU*.
> 
> Because then the problem really is you.
> 
> And in *both* of the examples you cite, that was exactly the issue. It
> wasn't that there was a bug - it was that the maintainer in question
> basically refused to fix a regression.
> 
> Sure, there was a code problem. But that wasn't the big issue. Code
> can be broken, and can be utter crap, but as long as it's fixed, who
> cares?
> 
> But when top-level maintainers start ignoring the #1 rule in the
> kernel ("We don't regress user space"), then it's not the broken code
> that annoys me any more.
> 
> See the difference?
> 
> And yes, people who don't get this are people who I will literally
> refuse to work with. In both of the cases you cite, things resolved
> themselves quickly (in fact, with Rafael it was at least partially
> just bad communication, and I haven't had that issue with him before).

Actually, I didn't feel like I was being attacked personally then.

In fact, I didn't say what I really wanted to say in that reply to the reporter
and that evidently confused you, which only made me think it was better to be
more careful about sending replies to regression reports when Linus is on the
CC list.  But it was kind of fun to watch you go ballistic by mistake. ;-)

And the problem itself was really confusing IIRC (that was a regression in a
piece of code that wasn't even executed as a result of a different bug and the
fix for that different bug caused the regression to show up).

So no, not really a good example of "Linus cursing at people" as far as I'm
concerned.

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [ 00/19] 3.10.1-stable review

[Willy Tarreau]

On Tue, Jul 16, 2013 at 02:08:56PM -0700, Sarah Sharp wrote:
> Rusty hit the nail on the head here.  I want everyone (including Linus)
> to be harsh with code but gentle with people.

Just as a side note Sarah, in some cultures/languages, "I want" is
extremely impolite, almost insulting to your interlocutor. In France,
if you want to quickly upset someone, simply say "I want you to do this
or that". The polite form is "I would like you to do that", "I would
appreciate..." or "let's do that", and when you're slightly upset or
in a hurry, better simply say "do that" without putting yourself
prominently as the one who has some unexplained reasons for demanding
something.

With that said, this thread has probably lived too long. I think we're
starting to fuck flies, and once we won't have any living flies left,
someone will have to bring new files, and it's certainly not me.

Regards,
Willy

Re: [ 00/19] 3.10.1-stable review

[Linus Torvalds]

On Tue, Jul 16, 2013 at 2:58 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>
> In fact, I didn't say what I really wanted to say in that reply to the reporter
> and that evidently confused you, which only made me think it was better to be
> more careful about sending replies to regression reports when Linus is on the
> CC list.  But it was kind of fun to watch you go ballistic by mistake. ;-)

And that's why I actually mentioned in my reply to Sarah that "(in
fact, with Rafael it was at least partially just bad communication,
and I haven't had that issue with him before)", because I have this
distinct memory that we ended up having that exact discussion about
misunderstanding and bad wording at the time.

I react very strongly when somebody argues against fixing regressions.
Let's just say that there's too many years of baggage that I carry
around on that issue..

So that is definitely one of the things that make me go ballistic.
Buggy code isn't actually one of them. Bugs happen. Even really stupid
bugs happen, and happen to good people. They had a bad day, or it was
just a brainfart.  Not that I will be _polite_ about bad code, mind
you, and there might be some bad words in there, but it doesn't make
me blow up.

Being cavalier about known regressions is definitely the primary
trigger. I suspect there are others, but I can't seem to recall any
other particular hot-button issues right now. Maybe Sarah can post a
few more pointers..

              Linus

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 4103 bytes --]

On Tue, 16 Jul 2013 22:27:09 +0400 James Bottomley
<James.Bottomley@HansenPartnership.com> wrote:

> On Mon, 2013-07-15 at 15:38 -0700, Linus Torvalds wrote:
> > On Mon, Jul 15, 2013 at 3:08 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > >
> > > Can we please make this into a Kernel Summit discussion. I highly doubt
> > > we would solve anything, but it certainly would be a fun segment to
> > > watch :-)
> > 
> > I think we should, because I think it's the kind of thing we really
> > need at the KS - talking about "process".
> 
> Can you formulate the process issue to discuss?  I've heard "Linus needs
> to yell less at people" and "the mailing lists need to be more
> 'professional'" neither of which seems to identify an actual process.
> Are we perhaps discussing guidelines for giving feedback on patches?
> 
> > At the same time, I really don't know what the format would possibly
> > be like for it to really work as a reasonable discussion. And I think
> > that is important, because this kind of subject is *not* likely
> > possible in the traditional "people sit around tables and maybe
> > somebody has a few slides" format.
> 
> > A small panel discussion with a few people (fiveish?) that have very
> > different viewpoints, along with baskets of rotten fruit set out on
> > the tables? That could be fun. And I'm serious, although we might want
> > to limit the size of the fruit to smaller berries ;)
> 
> How about Lychees?  They're prickly on the outside, very wet on the
> inside and have large stones ...
> 
> But what are the viewpoints?  "maintainers need to yell more"?
> "maintainers need to yell less"?  I don't think I agree with either.
> I'm perfectly happy to run linux-scsi along reasonable standards of
> civility and try to keep the debates technical, but that's far easier to
> do on a low traffic list; obviously, I realise that style of argument
> doesn't suit everyone, so it's not a standard of behaviour I'd like to
> see universally imposed.  In fact, I've got to say that I wouldn't like
> to see *any* behaviour standard imposed ... they're all basically cover
> for power plays (or soon get abused as power plays); the only real way
> to display leadership on behaviour standards is by example not by fiat.

I agree that we don't want a formal "standard of behaviour" - it would be just
as bad as the standard for white space.
I also agree that "by example" is the best way to affect behaviour standards.
However this effect can be positive or negative (or both).
And different people have widely varying opportunities to demonstrate
behaviour.

So I don't think this is about saying "maintainer need to do X".
It is about a non-trivial (I believe) section of the community saying "We are
bothered by the current de facto behavioural standard"  i.e. it is feed back
to those in a position to set standards, that their behaviour is having a
negative effect beyond their apparent intention.

Or if you want a sound-bite:

   With great power comes great responsibility.  Are we being responsible?

The particular issue that I see is the venting of negative emotion.  Email is
a particularly bad medium for communicating emotion.  People will *not* hear
what you are trying to say if it is couched in strongly emotional terms.
It isn't the particular word choice or whether the emotion is directed at a
person, or a piece of code, or a cat photo.  The presence of negative emotion
in an email will drown out everything else (for some readers at least, many
I believe, certainly not all).
So my personal perspective on what it means to be responsible is:

   Don't flame:  include the facts, exclude the emotion.

I have no desire to impose this on others, but I'm happy when people impose it
(or something like it) on themselves.

NeilBrown

> 
> James
> 
> 
> _______________________________________________
> Ksummit-2013-discuss mailing list
> Ksummit-2013-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-2013-discuss


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Willy Tarreau]

On Tue, Jul 16, 2013 at 02:12:35PM -0700, Sarah Sharp wrote:
> I *hate* both direct personal insults and indirect personal insults.
> Neither should be acceptable in our community.
> 
> As I stated in an email to Rusty, what I'm objecting to here is not
> kernel developers criticizing code.  I'm objecting to personal attacks,
> and developers directing personal verbal abuse towards each other.  This
> include all developers, not just Linus.

Well, there are people like me who don't mind getting personally
insulted but who are really pained when their work is criticized.

You'd rather tell me I'm a fucking moron than all what I carefully
designed, wrote and tested is pure crap. Probably that part of the
reason is that I'm as I am and I'm not really responsible for this,
so I don't care. Call me ugly if you want, why should I bother ? But
if you tell me I did some crap, it's entirely my fault and that hurts
a lot more.

So you want criticism to change focus for good, but it will not
necessarily achieve the result you're expecting. Maybe we can lose
more talented people by telling them their work is pure crap because
we did not understand it than telling them they're stupid and let
them argument their choices. At least I don't claim to know which
one is better, all I can say is that what we have right now works
well enough in my opinion.

Best regards,
Willy

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Sarah Sharp]

On Wed, Jul 17, 2013 at 12:18:21AM +0200, Willy Tarreau wrote:
> On Tue, Jul 16, 2013 at 02:12:35PM -0700, Sarah Sharp wrote:
> > I *hate* both direct personal insults and indirect personal insults.
> > Neither should be acceptable in our community.
> > 
> > As I stated in an email to Rusty, what I'm objecting to here is not
> > kernel developers criticizing code.  I'm objecting to personal attacks,
> > and developers directing personal verbal abuse towards each other.  This
> > include all developers, not just Linus.
> 
> Well, there are people like me who don't mind getting personally
> insulted but who are really pained when their work is criticized.
> 
> You'd rather tell me I'm a fucking moron than all what I carefully
> designed, wrote and tested is pure crap. Probably that part of the
> reason is that I'm as I am and I'm not really responsible for this,
> so I don't care. Call me ugly if you want, why should I bother ? But
> if you tell me I did some crap, it's entirely my fault and that hurts
> a lot more.

I think we come from different perspectives here.  I can change my code.
Therefore, I don't mind my code being insulted.  I cannot change myself.
Therefore, I don't want to read verbal abuse directed at me personally.

Things get blurred when we're talking about something a person did.
I can change how I act as a maintainer.  Therefore, tell me politely
what I did wrong, and I will change it.

> So you want criticism to change focus for good, but it will not
> necessarily achieve the result you're expecting. Maybe we can lose
> more talented people by telling them their work is pure crap because
> we did not understand it than telling them they're stupid and let
> them argument their choices. At least I don't claim to know which
> one is better, all I can say is that what we have right now works
> well enough in my opinion.

We can tell them their code is bad without calling it crap.  Cussing
them out is just a lazy shortcut.

Sarah Sharp

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Sarah Sharp]

On Tue, Jul 16, 2013 at 05:27:04PM -0400, Theodore Ts'o wrote:
> On Tue, Jul 16, 2013 at 02:12:35PM -0700, Sarah Sharp wrote:
> > "Your code is crap" is considered unprofessional, while
> > > "Let's leverage my fifth grade nephew's capabilities to assist you in
> > > fixing the code" is perfectly professional, somehow.  That's more
> > > often than not an unacceptable attitude in europe.
> > 
> > I *hate* both direct personal insults and indirect personal insults.
> > Neither should be acceptable in our community.
> 
> What is a "direct personal insult" can be in the eye of the beholder.
> Personally, I don't consider "your code is crap" as a personal insult.
> "You are an incompetent programmer for producing this crap" would be a
> personal attack.
> 
> Similarly, there is a difference between "That was an idiotic idea"
> and "You are an idiot".
> 
> Now, there are certainly more {diplomatic, politically correct,
> choose-your-own-favorite-adjective} ways wording the description of a
> particularly bad idea or piece of code.  But is that a "personal
> attack"?

I don't think we disagree on this, Ted.  I've stated that I view
personal attacks and insults negatively, and I don't see an issue with
pointing out that code is bad.  I think you're agreeing with me on this.

> Keep in mind that there are some cultures where even pointing out a
> technical flaw in code might considered bringing deep shame on the
> engineer and their company.  So how sensitive people are to criticism
> during an electronic exchange is always going to be highly culutrally
> and personally variable.

Yes, that's true.  Some kernel developers are better at moderating their
comments and tone towards individuals who are "sensitive".  Others
simply don't give a shit.  So we need to figure out how to meet
somewhere in the middle, in order to establish a baseline of civility.

Sarah Sharp

Re: [ATTEND] How to act on LKML

[Jiri Kosina]

On Tue, 16 Jul 2013, Stefano Stabellini wrote:

> > > I think that it's hurting Linux and in particular it's hurting
> > > attracting new talents.
> > 
> > Then why do we have the largest # of developers than any other Open
> > Source project?
> 
> Because Linux is the most widely used kernel, it's everywhere from
> embedded devices to supercomputers.

And that's because ... ?

Yes, because the community has been very open since its very beginning 
(and this is not "being open about why I hate you personally", but this is 
"being open about what I think about your code").

Plus there is a *LOT* of humor and sarcasm in all that. Which just 
contributes to working on linux kernel being fun. I'd absolutely like to 
keep that spirit.

If you guys now start telling others what is allowed and what is forbidden 
to say, you are going to destroy this completely.

I don't want to be a part of a community where you have to read a legal 
code before you can speak without fear of being accused of verbal 
violence.

This just doesn't fit into how people of my culture see the world; hence, 
I may even feel offended by Sarah's proposal (i.e. being very restrictive 
about what I am allowed to say), actually. I like openness, I like 
sarcasm, I like fun. Anyone who is trying to forbid this just doesn't fit 
into my culture.

> > Honestly, I think LKML over the years has become more tame. Yeah, back
> > in 2005 it was rather harsh, but I don't really see that anymore. I
> > don't see the nasty flame wars going on. Everything seems to be focused
> > more on the technical side, and there's really very little personal
> > attacks out there. Sure, with 15,000 emails a month, you get a few. And
> > Linus will get fed up and burst. But they are really few and far
> > between. And sometimes, a Linus burst gets things moving along much
> > faster than being "professional". You think ARM would have gotten their
> > act together as quick as they did if Linus didn't curse them out and
> > threaten to stop pulling their crap?
>  
> I think there is a way to get the point across without cursing.

Maybe there is, maybe there is not.

I am not cursing in my e-mails, you are probably neither. Linus is. Others 
are.

So what? He/they believe they achieves their goal through that mode of 
operation (and very often they indeed do), as so do we, through different 
means of communication.

No need to change anything anywhere. Please let everyone express their 
feelings the way the believe it's best for achieving their goals, and do 
the same.

-- 
Jiri Kosina
SUSE Labs

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Steven Rostedt]

On Tue, 2013-07-16 at 15:43 -0700, Sarah Sharp wrote:

> Yes, that's true.  Some kernel developers are better at moderating their
> comments and tone towards individuals who are "sensitive".  Others
> simply don't give a shit.  So we need to figure out how to meet
> somewhere in the middle, in order to establish a baseline of civility.

I have to ask this because I'm thick, and don't really understand,
but ...

What problem exactly are we trying to solve here?

-- Steve

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Randy Dunlap]

On 07/16/13 15:43, Sarah Sharp wrote:
> 
> Yes, that's true.  Some kernel developers are better at moderating their
> comments and tone towards individuals who are "sensitive".  Others
> simply don't give a shit.  So we need to figure out how to meet
> somewhere in the middle, in order to establish a baseline of civility.

So it's polite enough to curse if you don't direct it at anyone
in particular?  I'm sensitive so I disagree.

-- 
~Randy

Re: [ATTEND] How to act on LKML

[Randy Dunlap]

On 07/16/13 15:54, Jiri Kosina wrote:
> 
> Plus there is a *LOT* of humor and sarcasm in all that. Which just 
> contributes to working on linux kernel being fun. I'd absolutely like to 
> keep that spirit.
> 
> If you guys now start telling others what is allowed and what is forbidden 
> to say, you are going to destroy this completely.

Totally agreed.

And if Jim Z. wants to impose some standards on Linus, good luck with that.

> I don't want to be a part of a community where you have to read a legal 
> code before you can speak without fear of being accused of verbal 
> violence.
> 
> This just doesn't fit into how people of my culture see the world; hence, 
> I may even feel offended by Sarah's proposal (i.e. being very restrictive 
> about what I am allowed to say), actually. I like openness, I like 
> sarcasm, I like fun. Anyone who is trying to forbid this just doesn't fit 
> into my culture.
> 
> So what? He/they believe they achieves their goal through that mode of 
> operation (and very often they indeed do), as so do we, through different 
> means of communication.
> 
> No need to change anything anywhere. Please let everyone express their 
> feelings the way the believe it's best for achieving their goals, and do 
> the same.

Ack.  Thanks for expressing that.


-- 
~Randy

Re: [ATTEND] How to act on LKML

[Steven Rostedt]

On Wed, 2013-07-17 at 00:54 +0200, Jiri Kosina wrote:

> I am not cursing in my e-mails, you are probably neither. Linus is. Others 
> are.

I've been told several times that I'm one of the nicest on LKML. I like
to stick strictly to technical arguments, and will try to help people
out when I can.

The major difference between myself and Linus, is that I only have to
worry about code submissions, and to a much lesser degree than Linus.
But not only does Linus have to manage code, he also dictates policy.
And I'm not sure you can do that easily with cursing people out here and
there.

I have kids, and have run classes full of adults, and in both cases I
found that I had to yell "WHAT THE HELL IS THE MATTER WITH YOU" more
than once. Adults don't always act adult. Sometimes adults can be worse
than kids, as adults have a bit more feeling of power and can become
more argumentative. Although, my kids are now in their teenage years,
and there's a lot more yelling then there use to be.

Point is, I manage code, and don't really need to scold people to get
code right. Linus manages code and policy, and to get people to do
things correctly, and also to lay down his rule, he needs to whack us
from time to time.

-- Steve

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Sarah Sharp]

On Tue, Jul 16, 2013 at 06:54:59PM -0400, Steven Rostedt wrote:
> On Tue, 2013-07-16 at 15:43 -0700, Sarah Sharp wrote:
> 
> > Yes, that's true.  Some kernel developers are better at moderating their
> > comments and tone towards individuals who are "sensitive".  Others
> > simply don't give a shit.  So we need to figure out how to meet
> > somewhere in the middle, in order to establish a baseline of civility.
> 
> I have to ask this because I'm thick, and don't really understand,
> but ...
> 
> What problem exactly are we trying to solve here?

Personal attacks are not cool Steve.  Some people simply don't care if a
verbal tirade is directed at them.  Others do not want anyone to attack
them personally, but they're fine with people attacking their code.

Bystanders that don't understand the kernel community structure are
discouraged from contributing because they don't want to be verbally
abused, and they really don't want to see either personal attacks or
intense belittling, demeaning comments about code.

In order to make our community better, we need to figure out where the
baseline of "good" behavior is.  We need to define what behavior we want
from both maintainers and patch submitters.  E.g. "No regressions" and
"don't break userspace" and "no personal attacks".  That needs to be
written down somewhere, and it isn't.  If it's documented somewhere,
point me to the file in Documentation.  Hint: it's not there.

That is the problem.

Sarah Sharp

Re: [ATTEND] How to act on LKML

[Steven Rostedt]

On Tue, 2013-07-16 at 19:11 -0400, Steven Rostedt wrote:

> The major difference between myself and Linus, is that I only have to
> worry about code submissions, and to a much lesser degree than Linus.
> But not only does Linus have to manage code, he also dictates policy.
> And I'm not sure you can do that easily with cursing people out here and
> there.

Missed the double negative that was suppose to be there.
s/with/without/.

-- Steve

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Joe Perches]

On Tue, 2013-07-16 at 16:12 -0700, Sarah Sharp wrote:
> In order to make our community better, we need to figure out where the
> baseline of "good" behavior is.  We need to define what behavior we want
> from both maintainers and patch submitters.  E.g. "No regressions" and
> "don't break userspace" and "no personal attacks".  That needs to be
> written down somewhere, and it isn't.  If it's documented somewhere,
> point me to the file in Documentation.  Hint: it's not there.

So write a document, submit a patch and see what happens.

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Ric Wheeler]

On 07/16/2013 07:12 PM, Sarah Sharp wrote:
> On Tue, Jul 16, 2013 at 06:54:59PM -0400, Steven Rostedt wrote:
>> On Tue, 2013-07-16 at 15:43 -0700, Sarah Sharp wrote:
>>
>>> Yes, that's true.  Some kernel developers are better at moderating their
>>> comments and tone towards individuals who are "sensitive".  Others
>>> simply don't give a shit.  So we need to figure out how to meet
>>> somewhere in the middle, in order to establish a baseline of civility.
>> I have to ask this because I'm thick, and don't really understand,
>> but ...
>>
>> What problem exactly are we trying to solve here?
> Personal attacks are not cool Steve.  Some people simply don't care if a
> verbal tirade is directed at them.  Others do not want anyone to attack
> them personally, but they're fine with people attacking their code.
>
> Bystanders that don't understand the kernel community structure are
> discouraged from contributing because they don't want to be verbally
> abused, and they really don't want to see either personal attacks or
> intense belittling, demeaning comments about code.
>
> In order to make our community better, we need to figure out where the
> baseline of "good" behavior is.  We need to define what behavior we want
> from both maintainers and patch submitters.  E.g. "No regressions" and
> "don't break userspace" and "no personal attacks".  That needs to be
> written down somewhere, and it isn't.  If it's documented somewhere,
> point me to the file in Documentation.  Hint: it's not there.
>
> That is the problem.
>
> Sarah Sharp

The problem you are pointing out - and it is a problem - makes us less effective 
as a community.

Getting the balance right is clearly difficult in a large, diverse community, 
but I do think that the key is to focus criticism on the code or technical 
arguments and avoid attacks on the individual.

Being direct and funny in a critique is not the core of the issue,

Ric

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Steven Rostedt]

On Tue, 2013-07-16 at 16:12 -0700, Sarah Sharp wrote:

> > What problem exactly are we trying to solve here?
> 
> Personal attacks are not cool Steve.

I never said it was. But no matter what we do, people *will* be
offended. Can't help that.

>   Some people simply don't care if a
> verbal tirade is directed at them.  Others do not want anyone to attack
> them personally, but they're fine with people attacking their code.

If all you do is send code, then that's all that will happen. If you
start dictating policy, then it may be directed at you.

> 
> Bystanders that don't understand the kernel community structure are
> discouraged from contributing because they don't want to be verbally
> abused, and they really don't want to see either personal attacks or
> intense belittling, demeaning comments about code.

I wonder how true this is. I don't mean just any bystander, but people
that actually have code they could submit.

I'll admit that when I first started sending patches to LKML, I was
terrified. Not because I was afraid of being scolded, but because I was
afraid that what I sent wasn't good. It was a true judgment of my work.
I was prettified. Sure, I wouldn't have liked being insulted, but as
long as there was backing of why my work sucked I would be OK with it. I
actually had a rather good response to my work and I hung around.

But is there code existing out in the world that isn't in because people
are afraid of being insulted? Or afraid of their code being insulted? I
was the latter, and as we all seem to agree, the insulting of code is
what we want to keep.


> 
> In order to make our community better, we need to figure out where the
> baseline of "good" behavior is.

"community" has all sorts of behavior. The question is, is there really
a problem here? Sure some people don't like it, but they are still here.
Do you plan on leaving the Linux community if Linus doesn't change?

Now that would be a shame if you did, because you are a talented
developer. But I've never seen people insult you directly on LKML. I
don't know about private emails, but that's not the topic here.


>   We need to define what behavior we want
> from both maintainers and patch submitters.  E.g. "No regressions" and
> "don't break userspace"

Yes, those do need to be documented.


>  and "no personal attacks".

I actually disagree with this. What I would say this instead: "try to
keep it technical and focus on the code. If you are upset at someone,
think twice before hitting send. But if you really think this is the
only way to deal with the situation, then that's your call, and you get
to deal with the consequences."

I don't think changing peoples behavior is going to work. It wont. You
don't want to change who you are, others don't want to change who they
are. Deal with it. But what we can do is just try to educate people on
what policies are needed to be a maintainer and code submitter (there is
documentation already on some of this), and then point it to people. If
people continue to ignore those after being shown, then yes, personal
attacks are then in order.


>   That needs to be
> written down somewhere, and it isn't.  If it's documented somewhere,
> point me to the file in Documentation.  Hint: it's not there.

Well, SubmittingPatches is there, but we should have a MaintainerRules
or something.

> 
> That is the problem.

We can always use better documentation.

-- Steve

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Steven Rostedt]

On Tue, 2013-07-16 at 19:38 -0400, Steven Rostedt wrote:

> I'll admit that when I first started sending patches to LKML, I was
> terrified. Not because I was afraid of being scolded, but because I was
> afraid that what I sent wasn't good. It was a true judgment of my work.
> I was prettified. Sure, I wouldn't have liked being insulted, but as

OK, this has happened *again*! Really spell check? "pettrified" became
"prettified", and not "petrified"????

I just need to spell better :-p

Although, I have to admit, getting patches into the kernel has made me
prettier ;-)

-- Steve


> long as there was backing of why my work sucked I would be OK with it. I
> actually had a rather good response to my work and I hung around.

Re: [ATTEND] How to act on LKML

[Casey Schaufler]

On 7/16/2013 3:39 PM, Sarah Sharp wrote:
> On Wed, Jul 17, 2013 at 12:18:21AM +0200, Willy Tarreau wrote:
>> On Tue, Jul 16, 2013 at 02:12:35PM -0700, Sarah Sharp wrote:
>>> I *hate* both direct personal insults and indirect personal insults.
>>> Neither should be acceptable in our community.
>>>
>>> As I stated in an email to Rusty, what I'm objecting to here is not
>>> kernel developers criticizing code.  I'm objecting to personal attacks,
>>> and developers directing personal verbal abuse towards each other.  This
>>> include all developers, not just Linus.
>> Well, there are people like me who don't mind getting personally
>> insulted but who are really pained when their work is criticized.
>>
>> You'd rather tell me I'm a fucking moron than all what I carefully
>> designed, wrote and tested is pure crap. Probably that part of the
>> reason is that I'm as I am and I'm not really responsible for this,
>> so I don't care. Call me ugly if you want, why should I bother ? But
>> if you tell me I did some crap, it's entirely my fault and that hurts
>> a lot more.
> I think we come from different perspectives here.  I can change my code.
> Therefore, I don't mind my code being insulted.  I cannot change myself.

Sure you can, he began politely.

It's a process called personal growth, and it happens to most
of us as we go through life. It is in reasonable to expect change
and to some degree manage the way in which one's self changes. It
is unreasonable and expect to manage changes in others, although we
do insist on trying.

Communities develop expectations of behavior based on many factors.
No community responds well to individuals who demand changes in the
norms of the community. This is especially true when the change is
a demand that some aspect of the community that is seen as unique
or empowering by the members of the community be suppressed.

Email communities are notorious for what would be considered
inexcusable behavior in most other kinds of community. I do not
know of any explanation, nor will I attempt to justify the claim.
I suspect that the relative anonymity has something to do with it,
as does the fact you can't actually raise your voice or glare. Or
smile smugly, for that matter.

The norms of the Linux kernel community have changed over time,
and will continue to do so. Communities, like the individuals that
make them up, change over time. Linus and Al Viro have changed over
the years. I have changed over the years. If you stick around, you
will too. If you don't you'll still change, but in different ways.

The changes that the community makes may or may not suit you when
they happen. You can certainly work to influence the behavior of
the community. Demanding that the community change to suit your
desires doesn't work in your apartment building (dorm, homeowner's
association or county courthouse) either. That's basic social
behavior. Look to yourself for change before you look to change
others. It works better.

> Therefore, I don't want to read verbal abuse directed at me personally.
>
> Things get blurred when we're talking about something a person did.
> I can change how I act as a maintainer.  Therefore, tell me politely
> what I did wrong, and I will change it.
>
>> So you want criticism to change focus for good, but it will not
>> necessarily achieve the result you're expecting. Maybe we can lose
>> more talented people by telling them their work is pure crap because
>> we did not understand it than telling them they're stupid and let
>> them argument their choices. At least I don't claim to know which
>> one is better, all I can say is that what we have right now works
>> well enough in my opinion.
> We can tell them their code is bad without calling it crap.  Cussing
> them out is just a lazy shortcut.
>
> Sarah Sharp
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Theodore Ts'o]

On Tue, Jul 16, 2013 at 03:43:57PM -0700, Sarah Sharp wrote:
> I don't think we disagree on this, Ted.  I've stated that I view
> personal attacks and insults negatively, and I don't see an issue with
> pointing out that code is bad.  I think you're agreeing with me on this.

Perhaps I misundrestood you, then; when you replied to Olivier's
message, which used as his example "your code is crap", and "Let's
leverage my fifth grade nephew's capabilities to assist you in fixing
the code", it seemed to me that you called one a "personal attack",
and the other an "indirect personal insults".

If we're trying to say that "words matter", then it would be useful if
we are careful in what we describe as "a personal atack", and what
gets described as "abuse".

For example, when you brought up the example of Linus yelling at
Mauro, most of what I saw was Linus "yelling" (electronically) about
his behaviour being unacceptable.  I saw mostly, "your behaviour is
idiotic", not "you are an idiot".  Which perhaps is a finer gradation
than the difference between "your code is crap" and "you are crap".
Still, while I might call Linus's words to Mauro many things, "a
personal attack" wouldn't have been one of those words.  Emphatic?
Yes.  Yelling?  Yes.  Something I wouldn't do?  Probably.  But "A
personal attack"?  I'm not so sure.

And then when you start reading comments from folks forua suc as G+
and Hacker News calling Linus "a dick" or "a douchebag", the irony is
quite palpable....

> > Keep in mind that there are some cultures where even pointing out a
> > technical flaw in code might considered bringing deep shame on the
> > engineer and their company.  So how sensitive people are to criticism
> > during an electronic exchange is always going to be highly culutrally
> > and personally variable.
> 
> Yes, that's true.  Some kernel developers are better at moderating their
> comments and tone towards individuals who are "sensitive".  

... and actually, I think it's actually quite difficult to find cases
where Linus has used a very harsh tone towards someone who would be
"sensitive".  The argument which I've more commonly heard is one of
"collatoral damage".  That is, that people other than the transgressor
of the bad behaviour see Linus's messages, and (a) don't realize that
the vast majority of his e-mails are not that harsh, and (b) assume
that Linus would use that language on them.

And certainly that is a downside of sending messages of chastisement
publically rather than privately.  I doubt that neither Linus nor you
would disagee that there is a downside tradeoff.  On the other hand,
if such messages are sent priviately, they are much less useful as far
as establishing community norms around technical excellence,
especially in regards to "no regressions" and "don't break userspace".
I suspect that you and he come down on different sides of the
question, "is it worth the tradeoff".

The other question where I think you and Linus differ is the belief
whether polite messages of the form, "it's really rude to break the
kernel ABI, I would rather prefer if you wouldn't do that" are as
effective at establishing community norms, compared with his style of
e-mail messagtes, and whether the priority in establishing community
norms around technical excellence compares with the priority around
community norms around "civility".

(And of course, what is considered "civil", and what is considered a
"personal attack", and what isn't.)

Hopefully this helps to clarify the discussion.  I'm trying rather
purposely not take one side or another, but instead trying to
articulate what I think I've been hearing people say (over, and over,
and over again, on this very long mail thread).

Regards,

						- Ted

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Myklebust, Trond]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2659 bytes --]

On Tue, 2013-07-16 at 19:31 -0400, Ric Wheeler wrote:
> On 07/16/2013 07:12 PM, Sarah Sharp wrote:
> > On Tue, Jul 16, 2013 at 06:54:59PM -0400, Steven Rostedt wrote:
> >> On Tue, 2013-07-16 at 15:43 -0700, Sarah Sharp wrote:
> >>
> >>> Yes, that's true.  Some kernel developers are better at moderating their
> >>> comments and tone towards individuals who are "sensitive".  Others
> >>> simply don't give a shit.  So we need to figure out how to meet
> >>> somewhere in the middle, in order to establish a baseline of civility.
> >> I have to ask this because I'm thick, and don't really understand,
> >> but ...
> >>
> >> What problem exactly are we trying to solve here?
> > Personal attacks are not cool Steve.  Some people simply don't care if a
> > verbal tirade is directed at them.  Others do not want anyone to attack
> > them personally, but they're fine with people attacking their code.
> >
> > Bystanders that don't understand the kernel community structure are
> > discouraged from contributing because they don't want to be verbally
> > abused, and they really don't want to see either personal attacks or
> > intense belittling, demeaning comments about code.
> >
> > In order to make our community better, we need to figure out where the
> > baseline of "good" behavior is.  We need to define what behavior we want
> > from both maintainers and patch submitters.  E.g. "No regressions" and
> > "don't break userspace" and "no personal attacks".  That needs to be
> > written down somewhere, and it isn't.  If it's documented somewhere,
> > point me to the file in Documentation.  Hint: it's not there.
> >
> > That is the problem.
> >
> > Sarah Sharp
> 
> The problem you are pointing out - and it is a problem - makes us less effective 
> as a community.

Not really. Most of the people who already work as part of this
community are completely used to it. We've created the environment, and
have no problems with it.

Where it could possibly be a problem is when it comes to recruiting
_new_ members to our community. Particularly so given that some
journalists take a special pleasure in reporting particularly juicy
comments and antics. That would tend to scare off a lot of gun-shy
newbies.
On the other hand, it might tend to bias our recruitment toward people
of a more "special" disposition. Perhaps we finally need the services of
a social scientist to help us find out...

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Myklebust, Trond]

On Tue, 2013-07-16 at 19:31 -0400, Ric Wheeler wrote:
> On 07/16/2013 07:12 PM, Sarah Sharp wrote:
> > On Tue, Jul 16, 2013 at 06:54:59PM -0400, Steven Rostedt wrote:
> >> On Tue, 2013-07-16 at 15:43 -0700, Sarah Sharp wrote:
> >>
> >>> Yes, that's true.  Some kernel developers are better at moderating their
> >>> comments and tone towards individuals who are "sensitive".  Others
> >>> simply don't give a shit.  So we need to figure out how to meet
> >>> somewhere in the middle, in order to establish a baseline of civility.
> >> I have to ask this because I'm thick, and don't really understand,
> >> but ...
> >>
> >> What problem exactly are we trying to solve here?
> > Personal attacks are not cool Steve.  Some people simply don't care if a
> > verbal tirade is directed at them.  Others do not want anyone to attack
> > them personally, but they're fine with people attacking their code.
> >
> > Bystanders that don't understand the kernel community structure are
> > discouraged from contributing because they don't want to be verbally
> > abused, and they really don't want to see either personal attacks or
> > intense belittling, demeaning comments about code.
> >
> > In order to make our community better, we need to figure out where the
> > baseline of "good" behavior is.  We need to define what behavior we want
> > from both maintainers and patch submitters.  E.g. "No regressions" and
> > "don't break userspace" and "no personal attacks".  That needs to be
> > written down somewhere, and it isn't.  If it's documented somewhere,
> > point me to the file in Documentation.  Hint: it's not there.
> >
> > That is the problem.
> >
> > Sarah Sharp
> 
> The problem you are pointing out - and it is a problem - makes us less effective 
> as a community.

Not really. Most of the people who already work as part of this
community are completely used to it. We've created the environment, and
have no problems with it.

Where it could possibly be a problem is when it comes to recruiting
_new_ members to our community. Particularly so given that some
journalists take a special pleasure in reporting particularly juicy
comments and antics. That would tend to scare off a lot of gun-shy
newbies.
On the other hand, it might tend to bias our recruitment toward people
of a more "special" disposition. Perhaps we finally need the services of
a social scientist to help us find out...

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Steven Rostedt]

On Tue, 2013-07-16 at 19:50 -0400, Theodore Ts'o wrote:

> Hopefully this helps to clarify the discussion.  I'm trying rather
> purposely not take one side or another, but instead trying to
> articulate what I think I've been hearing people say (over, and over,
> and over again, on this very long mail thread).

I'll end the thread now...


Dictating what you can or can not say is what the Nazis would do.

There, now that Godwin's Rule has been satisfied, lets just continue
this discussion at Kernel Summit. I doubt anything will change before
then.


-- Steve

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Jeff Liu]

On 07/17/2013 07:12 AM, Sarah Sharp wrote:

> On Tue, Jul 16, 2013 at 06:54:59PM -0400, Steven Rostedt wrote:
>> On Tue, 2013-07-16 at 15:43 -0700, Sarah Sharp wrote:
>>
>>> Yes, that's true.  Some kernel developers are better at moderating their
>>> comments and tone towards individuals who are "sensitive".  Others
>>> simply don't give a shit.  So we need to figure out how to meet
>>> somewhere in the middle, in order to establish a baseline of civility.
>>
>> I have to ask this because I'm thick, and don't really understand,
>> but ...
>>
>> What problem exactly are we trying to solve here?
> 
> Personal attacks are not cool Steve.  Some people simply don't care if a
> verbal tirade is directed at them.  Others do not want anyone to attack
> them personally, but they're fine with people attacking their code.

+1
I accept someone attaching my code, but it's better if he/she can
point me out why the code is stupid. :)

> 
> Bystanders that don't understand the kernel community structure are
> discouraged from contributing because they don't want to be verbally
> abused, and they really don't want to see either personal attacks or
> intense belittling, demeaning comments about code.

I feel the same way.

> 
> In order to make our community better, we need to figure out where the
> baseline of "good" behavior is.  We need to define what behavior we want
> from both maintainers and patch submitters.  E.g. "No regressions" and
> "don't break userspace" and "no personal attacks".  That needs to be
> written down somewhere, and it isn't.  If it's documented somewhere,
> point me to the file in Documentation.  Hint: it's not there.

Another thing might deviated from the main theme, but I'd like to raise it
here because I would like to see what's the proper way for that.

For instance, people A posted a patch set to the mailing list at first,
people B think that there are some issues in A's implementation, and he
happened to play around the same stuff recently, so he submitted another
patch series.  Finally, people B made it.
(In that period, people A kept silent, maybe because he/she was unhappy) 

This is a actual occurrence I once observed from a subsystem list(my
apologies, I just want to talk this case rather than against somebody),
it seems people A is a new comer(because I can not searched any past
commits of him/her from the git log), people B is definitely a senior guy.

So that's my question, is that a proper collaboration form in kernel
community?  Does it better if people B could give some suggestions to
help A to improve the code, especially if those help would help A stepping
into the kernel development -- maybe it's depend largely on one's opinion. :(


Thanks,
-Jeff

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Steven Rostedt]

On Wed, 2013-07-17 at 08:32 +0800, Jeff Liu wrote:

> Another thing might deviated from the main theme, but I'd like to raise it
> here because I would like to see what's the proper way for that.
> 
> For instance, people A posted a patch set to the mailing list at first,
> people B think that there are some issues in A's implementation, and he
> happened to play around the same stuff recently, so he submitted another
> patch series.  Finally, people B made it.
> (In that period, people A kept silent, maybe because he/she was unhappy) 
> 
> This is a actual occurrence I once observed from a subsystem list(my
> apologies, I just want to talk this case rather than against somebody),
> it seems people A is a new comer(because I can not searched any past
> commits of him/her from the git log), people B is definitely a senior guy.
> 
> So that's my question, is that a proper collaboration form in kernel
> community?  Does it better if people B could give some suggestions to
> help A to improve the code, especially if those help would help A stepping
> into the kernel development -- maybe it's depend largely on one's opinion. :(

This is a completely different issue from the one in this thread, but it
is also a legitimate issue and honestly, a bigger one than perceived
insults.

Is it proper collaboration? Absolutely not. Something that I try to be
sensitive to as it's something I can do as well. There's been things on
my todo list, where someone would send me patches that do it. I would be
thinking "darn it, I wanted to do it" and even worse, the patches that
were sent wouldn't be of the way I wanted them. But I've tried to be
good, and instead of just going about and implementing it myself, I
would try to help the person massage the patches into what I wanted.
That takes a lot of effort and discipline, and honestly, helping someone
else do the work you wanted is much harder than just doing it yourself. 

Sometimes the maintainer just takes the easier route, and does the work
themselves (because it's also more fun too). But that's really a slap in
the face of the person that submitted the work in the first place. If
anything hurts the community, it's this behavior. Not Linus giving
someone an ass wipe.

-- Steve
 

Re: [ATTEND] How to act on LKML

[Sarah Sharp]

On Tue, Jul 16, 2013 at 04:46:33PM -0700, Casey Schaufler wrote:
> On 7/16/2013 3:39 PM, Sarah Sharp wrote:
> > On Wed, Jul 17, 2013 at 12:18:21AM +0200, Willy Tarreau wrote:
> >> On Tue, Jul 16, 2013 at 02:12:35PM -0700, Sarah Sharp wrote:
> >>> I *hate* both direct personal insults and indirect personal insults.
> >>> Neither should be acceptable in our community.
> >>>
> >>> As I stated in an email to Rusty, what I'm objecting to here is not
> >>> kernel developers criticizing code.  I'm objecting to personal attacks,
> >>> and developers directing personal verbal abuse towards each other.  This
> >>> include all developers, not just Linus.
> >> Well, there are people like me who don't mind getting personally
> >> insulted but who are really pained when their work is criticized.
> >>
> >> You'd rather tell me I'm a fucking moron than all what I carefully
> >> designed, wrote and tested is pure crap. Probably that part of the
> >> reason is that I'm as I am and I'm not really responsible for this,
> >> so I don't care. Call me ugly if you want, why should I bother ? But
> >> if you tell me I did some crap, it's entirely my fault and that hurts
> >> a lot more.
> > I think we come from different perspectives here.  I can change my code.
> > Therefore, I don't mind my code being insulted.  I cannot change myself.
> 
> Sure you can, he began politely.
> 
> It's a process called personal growth, and it happens to most
> of us as we go through life. It is in reasonable to expect change
> and to some degree manage the way in which one's self changes. It
> is unreasonable and expect to manage changes in others, although we
> do insist on trying.

Personal change does happen, but at a much slower pace.  And it takes
both a will to change, and incentive in order for change to happen.  If
someone wants personal change in others or in the community, there needs
to be both incentive to change, and a will to change in the community.

I've provided examples and personal stories in an attempt to give
incentive to change.  I cannot force on anyone the will to change, nor
would I want to.  I cannot "manage" change in others.  I can only
politely point out that the current community behavior does hurt other
people, and keep people from contributing.

> Communities develop expectations of behavior based on many factors.
> No community responds well to individuals who demand changes in the
> norms of the community. This is especially true when the change is
> a demand that some aspect of the community that is seen as unique
> or empowering by the members of the community be suppressed.

The majority in the community never reacts well to minority voices in
the community asking for change.  (Note, I'm talking a majority of
numbers, not a racial or gender minority.)

I'm not demanding change.  I'm merely asking to discuss the possibly of
change at KS.

> Email communities are notorious for what would be considered
> inexcusable behavior in most other kinds of community. I do not
> know of any explanation, nor will I attempt to justify the claim.
> I suspect that the relative anonymity has something to do with it,
> as does the fact you can't actually raise your voice or glare. Or
> smile smugly, for that matter.

I do smile often in email. :)  And be sad. :( And be apologetic. :-/
Smug. ^~^  Angry. >:[  Sarcastic. ;)  Trolling/crazy. 8)  D'oh. (>.<)
Worried. (>_>);  Disappointed. (-_-)  Kitty! =^_^=  Meow!

Be creative.  There are ways of expressing emotion without cussing.

> The norms of the Linux kernel community have changed over time,
> and will continue to do so. Communities, like the individuals that
> make them up, change over time. Linus and Al Viro have changed over
> the years. I have changed over the years. If you stick around, you
> will too. If you don't you'll still change, but in different ways.

I do believe I have changed over the six years I've been involved in
the kernel.  If anything, I've gotten better at being loud, speaking my
mind, and figuring out what's bad code and how to politely tell people I
don't take their code.

I do think it is a mark of respect, both from the community, and from
me, that people are actually listening and responding to me raising this
issue.  The discussion has been mainly civil, even if we disagree.
Five, ten years ago, I probably would have gotten flamed out of the
community entirely.

So, in short, thank you for listening.  We may disagree, but I
appreciate being listened to.

> The changes that the community makes may or may not suit you when
> they happen. You can certainly work to influence the behavior of
> the community. Demanding that the community change to suit your
> desires doesn't work in your apartment building (dorm, homeowner's
> association or county courthouse) either. That's basic social
> behavior. Look to yourself for change before you look to change
> others. It works better.

As I mentioned, I have changed much over the past six years.  I suspect
this particular thread will change me, although over a longer period of
time, and in ways that may not be immediately obvious to the community.
I suspect the same will be true of changes in the community.

The point is that if no one stands up and asks for change, nothing will
change.  I do not demand, I merely ask for people to consider change.

Sarah Sharp

Re: [ 00/19] 3.10.1-stable review

[Rusty Russell]

Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:
> On Tue, Jul 16, 2013 at 02:22:14PM +0930, Rusty Russell wrote:
> Linus is complaining about code here, and the effects of merging bad
> code on his own tree.  I personally have no qualms with this type of
> harsh email, because it focuses on the code, not the person.
>
> I do, however, object when the verbal abuse shifts from being directed
> at code to being directed at *people*.  For example, Linus chose to
> curse at Mauro [2] and Rafael [3], rather than their code:
>
>
> "Mauro, SHUT THE FUCK UP!"

This one crosses the line.  There's no non-offensive way to tell a geek
"you are wrong", but this isn't even trying.  Bad Linus!

> "How long have you been a maintainer? And you *still* haven't learnt the
> first rule of kernel maintenance?"
>
> "Shut up, Mauro. And I don't _ever_ want to hear that kind of obvious
> garbage and idiocy from a kernel maintainer again. Seriously."
>
> "The fact that you then try to make *excuses* for breaking user space,
> and blaming some external program that *used* to work, is just
> shameful. It's not how we work."
>
> "Fix your f*cking "compliance tool", because it is obviously broken.
> And fix your approach to kernel programming."
...
> ...and I'm surprised to
> hear that kind of utter garbage from you in particular."

Linus repeats 5 times: you can tell he's upset.

> "Seriously. Why do I even have to mention this? Why do I have to
> explain this to somebody pretty much *every* f*cking merge window?"

This one is OK, actually.

So, I tried to rewrite Linus' email.  And it lost the raw, red-hot anger
of the original.  It no longer makes everyone listen.  It tempts one to
argue.

It is not as effective :(

But suggesting alternate expressions might be constructive.
Rusty.

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Ric Wheeler]

On 07/16/2013 07:53 PM, Myklebust, Trond wrote:
> On Tue, 2013-07-16 at 19:31 -0400, Ric Wheeler wrote:
>> On 07/16/2013 07:12 PM, Sarah Sharp wrote:
>>> On Tue, Jul 16, 2013 at 06:54:59PM -0400, Steven Rostedt wrote:
>>>> On Tue, 2013-07-16 at 15:43 -0700, Sarah Sharp wrote:
>>>>
>>>>> Yes, that's true.  Some kernel developers are better at moderating their
>>>>> comments and tone towards individuals who are "sensitive".  Others
>>>>> simply don't give a shit.  So we need to figure out how to meet
>>>>> somewhere in the middle, in order to establish a baseline of civility.
>>>> I have to ask this because I'm thick, and don't really understand,
>>>> but ...
>>>>
>>>> What problem exactly are we trying to solve here?
>>> Personal attacks are not cool Steve.  Some people simply don't care if a
>>> verbal tirade is directed at them.  Others do not want anyone to attack
>>> them personally, but they're fine with people attacking their code.
>>>
>>> Bystanders that don't understand the kernel community structure are
>>> discouraged from contributing because they don't want to be verbally
>>> abused, and they really don't want to see either personal attacks or
>>> intense belittling, demeaning comments about code.
>>>
>>> In order to make our community better, we need to figure out where the
>>> baseline of "good" behavior is.  We need to define what behavior we want
>>> from both maintainers and patch submitters.  E.g. "No regressions" and
>>> "don't break userspace" and "no personal attacks".  That needs to be
>>> written down somewhere, and it isn't.  If it's documented somewhere,
>>> point me to the file in Documentation.  Hint: it's not there.
>>>
>>> That is the problem.
>>>
>>> Sarah Sharp
>> The problem you are pointing out - and it is a problem - makes us less effective
>> as a community.
> Not really. Most of the people who already work as part of this
> community are completely used to it. We've created the environment, and
> have no problems with it.

You should never judge success by being popular with those people who are 
already contributing and put up with things. If you did that in business, you 
would never reach new customers.

>
> Where it could possibly be a problem is when it comes to recruiting
> _new_ members to our community. Particularly so given that some
> journalists take a special pleasure in reporting particularly juicy
> comments and antics. That would tend to scare off a lot of gun-shy
> newbies.

That is my point - recruiting new members is made harder. As some one who 
manages *a lot* of upstream kernel developers, I will add that it is not just 
new comers that find this occasionally offensive and off putting.

> On the other hand, it might tend to bias our recruitment toward people
> of a more "special" disposition. Perhaps we finally need the services of
> a social scientist to help us find out...
>

To be fair, we usually do very well at this, especially with new comers to our 
community.

I think that most of the problems come up between people who know each other 
quite well and are friendly with each other in person. The problem is that when 
you use language that you would use with good friends over drinks to tell them 
they are being stupid and do that on a public list, you set a tone that reaches 
far beyond your intended target. All of those new comers also read this list and 
do not see it as funny or friendly.

I really don't think that we have to be politically correct or overly kind to 
make things better.

As a very low bar, we could start by trying to avoid using language that would 
get you fired when you send off an email to someone that you have power over 
(either manage directly or indirectly control their career).

Ric

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Ric Wheeler]

On 07/16/2013 07:53 PM, Myklebust, Trond wrote:
> On Tue, 2013-07-16 at 19:31 -0400, Ric Wheeler wrote:
>> On 07/16/2013 07:12 PM, Sarah Sharp wrote:
>>> On Tue, Jul 16, 2013 at 06:54:59PM -0400, Steven Rostedt wrote:
>>>> On Tue, 2013-07-16 at 15:43 -0700, Sarah Sharp wrote:
>>>>
>>>>> Yes, that's true.  Some kernel developers are better at moderating their
>>>>> comments and tone towards individuals who are "sensitive".  Others
>>>>> simply don't give a shit.  So we need to figure out how to meet
>>>>> somewhere in the middle, in order to establish a baseline of civility.
>>>> I have to ask this because I'm thick, and don't really understand,
>>>> but ...
>>>>
>>>> What problem exactly are we trying to solve here?
>>> Personal attacks are not cool Steve.  Some people simply don't care if a
>>> verbal tirade is directed at them.  Others do not want anyone to attack
>>> them personally, but they're fine with people attacking their code.
>>>
>>> Bystanders that don't understand the kernel community structure are
>>> discouraged from contributing because they don't want to be verbally
>>> abused, and they really don't want to see either personal attacks or
>>> intense belittling, demeaning comments about code.
>>>
>>> In order to make our community better, we need to figure out where the
>>> baseline of "good" behavior is.  We need to define what behavior we want
>>> from both maintainers and patch submitters.  E.g. "No regressions" and
>>> "don't break userspace" and "no personal attacks".  That needs to be
>>> written down somewhere, and it isn't.  If it's documented somewhere,
>>> point me to the file in Documentation.  Hint: it's not there.
>>>
>>> That is the problem.
>>>
>>> Sarah Sharp
>> The problem you are pointing out - and it is a problem - makes us less effective
>> as a community.
> Not really. Most of the people who already work as part of this
> community are completely used to it. We've created the environment, and
> have no problems with it.

You should never judge success by being popular with those people who are 
already contributing and put up with things. If you did that in business, you 
would never reach new customers.

>
> Where it could possibly be a problem is when it comes to recruiting
> _new_ members to our community. Particularly so given that some
> journalists take a special pleasure in reporting particularly juicy
> comments and antics. That would tend to scare off a lot of gun-shy
> newbies.

That is my point - recruiting new members is made harder. As some one who 
manages *a lot* of upstream kernel developers, I will add that it is not just 
new comers that find this occasionally offensive and off putting.

> On the other hand, it might tend to bias our recruitment toward people
> of a more "special" disposition. Perhaps we finally need the services of
> a social scientist to help us find out...
>

To be fair, we usually do very well at this, especially with new comers to our 
community.

I think that most of the problems come up between people who know each other 
quite well and are friendly with each other in person. The problem is that when 
you use language that you would use with good friends over drinks to tell them 
they are being stupid and do that on a public list, you set a tone that reaches 
far beyond your intended target. All of those new comers also read this list and 
do not see it as funny or friendly.

I really don't think that we have to be politically correct or overly kind to 
make things better.

As a very low bar, we could start by trying to avoid using language that would 
get you fired when you send off an email to someone that you have power over 
(either manage directly or indirectly control their career).

Ric

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Sarah Sharp]

On Tue, Jul 16, 2013 at 08:51:36PM -0400, Steven Rostedt wrote:
> On Wed, 2013-07-17 at 08:32 +0800, Jeff Liu wrote:
> 
> > Another thing might deviated from the main theme, but I'd like to raise it
> > here because I would like to see what's the proper way for that.
> > 
> > For instance, people A posted a patch set to the mailing list at first,
> > people B think that there are some issues in A's implementation, and he
> > happened to play around the same stuff recently, so he submitted another
> > patch series.  Finally, people B made it.
> > (In that period, people A kept silent, maybe because he/she was unhappy) 
> > 
> > This is a actual occurrence I once observed from a subsystem list(my
> > apologies, I just want to talk this case rather than against somebody),
> > it seems people A is a new comer(because I can not searched any past
> > commits of him/her from the git log), people B is definitely a senior guy.
> > 
> > So that's my question, is that a proper collaboration form in kernel
> > community?  Does it better if people B could give some suggestions to
> > help A to improve the code, especially if those help would help A stepping
> > into the kernel development -- maybe it's depend largely on one's opinion. :(
> 
> This is a completely different issue from the one in this thread, but it
> is also a legitimate issue and honestly, a bigger one than perceived
> insults.
> 
> Is it proper collaboration? Absolutely not. Something that I try to be
> sensitive to as it's something I can do as well. There's been things on
> my todo list, where someone would send me patches that do it. I would be
> thinking "darn it, I wanted to do it" and even worse, the patches that
> were sent wouldn't be of the way I wanted them. But I've tried to be
> good, and instead of just going about and implementing it myself, I
> would try to help the person massage the patches into what I wanted.
> That takes a lot of effort and discipline, and honestly, helping someone
> else do the work you wanted is much harder than just doing it yourself. 
>
> Sometimes the maintainer just takes the easier route, and does the work
> themselves (because it's also more fun too). But that's really a slap in
> the face of the person that submitted the work in the first place. If
> anything hurts the community, it's this behavior. Not Linus giving
> someone an ass wipe.

/me hands Steve a box of wet-wipes. :)

There's a lot of controversy over whether a senior developer
re-implementing someone's patchset is bad behavior.  I've seen it argued
both ways.  "If I don't write code, I will just become a patch-pushing,
pencil-pushing maintainer."  Or "I don't want to bother working with
newbies, it's faster to just implement this myself."

I really think it's up to the maintainer whether they want to mentor
someone through a big submission, or do it themselves.  I usually lean
towards mentorship, but hey, not everyone has the time.

One thing that might make it easier for the original submitter is making
sure they get a Signed-off-by line in the patchset that the maintainer
submits.  At the very least, their line should be directly below the
maintainer's.  That way, they get credit for the idea, and possibly help
improve their statistics in the Signed-off-by count for that kernel
revision.

I suspect people would object if I suggested the original submitter
should be the first Signed-off-by line, but in some cases it may be
appropriate.  Sometimes I take someone's code, leave it mostly intact,
and fix the bugs or add a feature that we really need before the code
can land.  In that case, it makes sense to give the original submitter
credit before the maintainer.

Sarah Sharp

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]

On Tue, 16 Jul 2013 19:50:08 -0400 Theodore Ts'o <tytso@mit.edu> wrote:

> The other question where I think you and Linus differ is the belief
> whether polite messages of the form, "it's really rude to break the
> kernel ABI, I would rather prefer if you wouldn't do that" are as
> effective at establishing community norms, compared with his style of
> e-mail messagtes, and whether the priority in establishing community
> norms around technical excellence compares with the priority around
> community norms around "civility".

Can I call "strawman" here?

A maintainer has a significant power - to accept, reject, or revert.
I fully expect them to use that power.
Linus (or any other maintainer) doesn't need to say "I would rather prefer
if you wouldn't do that".
They say:
   This is wrong.  I will not accept that patch.
or
   This was wrong. I have reverted it.

And when absolutely necessary: "After a long succession of uncorrected
errors I regret to advise you that I can no longer consider any patches you
send".

Using emotive language is an attempt to control someone else by addressing
them at an emotional level.  That sort of control is not needed when the
above power is available, and it is a sort of control which is out of context
and can affect different people very very differently.

Personally, I find that a blunt but civil acceptance or rejection of patches
is quite sufficient to establish community norms of technical excellence.
Beyond that there are plenty of examples of very helpful and constructive
dialogue that improve patch quality even more.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ 00/19] 3.10.1-stable review

[Linus Torvalds]

On Tue, Jul 16, 2013 at 6:02 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>>
>> "Mauro, SHUT THE FUCK UP!"
>
> This one crosses the line.  There's no non-offensive way to tell a geek
> "you are wrong", but this isn't even trying.  Bad Linus!

You know what? Not my proudest moment. I was really upset.

But that said, in my defense I actually think that one stands out. I
have written a lot of public emails, and that one line is probably the
single most over-the-line one. Or at least pretty close to the top.
And it's not so much because of the swearing, but because of the "shut
up" part. Or is that just me not reacting to swearwords again?

Do I go overboard sometimes? Hell yes. But I get emotional about some
of this, and I not only think that's ok, I actually think it's
important. You mentioned the "lost the raw, red-hot anger of the
original", and I do think emotion is important to convey. It's not
just the message, it's also the fact that I'm really really pissed.

Neil Brown here somewhere earlier said

  "So my personal perspective on what it means to be responsible is:

   Don't flame:  include the facts, exclude the emotion."

and I can't overstate how much I disagree. You do need the factual
part too, but "exclude the emotion" is not good either.

Emotions aren't bad. Quite the reverse. If we are expected to have a
sense of personal trust between the people involved (and quite
frankly, apart from just "technical excellence" I think personal trust
is just about the top criterion for good maintainers), I definitely
think that it's not about just about the facts. You need to hear the
*person* too. And some people are calm and don't swear, and that's
them. Others aren't.

Yeah, yeah, I go overboard. Whatever. At least you guys know that when
I get emotional, I'm not going to come asking for a shoulder to cry
on.

I think a little excessive swearing is less awkward for everybody in the end.

            Linus

Side note: the whole "trust the person" doesn't mean you have to like
that person. "Trust" is about having your expectations met, not
necessarily about those expectations always being all that positive. .

Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Tue, 2013-07-16 at 18:37 -0700, Linus Torvalds wrote:

> Emotions aren't bad. Quite the reverse. 

Spock and Dr. Sheldon Cooper strongly disagree.

-- Steve

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]

On Tue, 2013-07-16 at 19:50 -0400, Theodore Ts'o wrote:
> On Tue, Jul 16, 2013 at 03:43:57PM -0700, Sarah Sharp wrote:
[...]
> > > Keep in mind that there are some cultures where even pointing out a
> > > technical flaw in code might considered bringing deep shame on the
> > > engineer and their company.  So how sensitive people are to criticism
> > > during an electronic exchange is always going to be highly culutrally
> > > and personally variable.
> > 
> > Yes, that's true.  Some kernel developers are better at moderating their
> > comments and tone towards individuals who are "sensitive".  
> 
> ... and actually, I think it's actually quite difficult to find cases
> where Linus has used a very harsh tone towards someone who would be
> "sensitive".
[...]

Someone wrote on debian-private a little while back that 'I will not
work on anything Linus might be involved in', and in a later mail linked
to this example of abuse:

http://mark.dreamwidth.org/22320.html

Honestly, if I had seen newbies being treated that way before I was
involved, I may well have made the same resolution.  As it happens, when
I made a quite basic mistake in the format one of my first patches back
in 1999, Linus was entirely polite in correcting me.

In fact, even in the pull request that's referenced here, Linus, you
were polite but firm in your first two responses.  When you're perfectly
capable of doing that, why spoil it by adding insults?

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Linus Torvalds]

On Tue, Jul 16, 2013 at 7:18 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
>
> In fact, even in the pull request that's referenced here, Linus, you
> were polite but firm in your first two responses.  When you're perfectly
> capable of doing that, why spoil it by adding insults?

Umm. Notice how the "Joseph" I replied to had deleted all the comments he wrote?

That should tell you something. I smacked down a troll.

If I was polite to you all those years ago, and I was polite but firm
in the two first responses, please give me credit for when I smack
somebody down. There may be a reason for it. The fact that the person
deleted his messages (or github deleted them for him - I have no idea
what their comment policy is) and you cannot see that context any more
online should not make you think that I suddenly went crazy.

Btw, since I get the github messages in email too, I have a copy.
Joseph replied to those "polite but firm" messages where I explained
exactly *why* I don't want to bother with github pull requests with
this gem:

   "I did not realizes that Linus' shit does not stink.  Thanks for
clearing that up..."

Quite frankly, I think I was quite polite enough. Exactly *because* I
had been polite but firm before that injection.

The fact is, I don't suffer fools nicely. I call it like I see it, and
I called him a moron for entering the discussion with a totally
content-free comment.

Feel free to disagree. Maybe you see some value in the troll comment?

And I somehow suspect that your message that I replied to back in 1999
was somehow more relevant? Yes? No?

                 Linus

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1977 bytes --]

On Tue, 2013-07-16 at 20:02 -0700, Linus Torvalds wrote:
> On Tue, Jul 16, 2013 at 7:18 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> >
> > In fact, even in the pull request that's referenced here, Linus, you
> > were polite but firm in your first two responses.  When you're perfectly
> > capable of doing that, why spoil it by adding insults?
> 
> Umm. Notice how the "Joseph" I replied to had deleted all the comments he wrote?

Sorry, that completely escaped me.

> That should tell you something. I smacked down a troll.
> 
> If I was polite to you all those years ago, and I was polite but firm
> in the two first responses, please give me credit for when I smack
> somebody down. There may be a reason for it. The fact that the person
> deleted his messages (or github deleted them for him - I have no idea
> what their comment policy is) and you cannot see that context any more
> online should not make you think that I suddenly went crazy.

Unfortunately, it seems I'm not the only one to be confused by this.

> Btw, since I get the github messages in email too, I have a copy.
> Joseph replied to those "polite but firm" messages where I explained
> exactly *why* I don't want to bother with github pull requests with
> this gem:
> 
>    "I did not realizes that Linus' shit does not stink.  Thanks for
> clearing that up..."
> 
> Quite frankly, I think I was quite polite enough. Exactly *because* I
> had been polite but firm before that injection.
> 
> The fact is, I don't suffer fools nicely. I call it like I see it, and
> I called him a moron for entering the discussion with a totally
> content-free comment.
> 
> Feel free to disagree. Maybe you see some value in the troll comment?

Indeed not.

> And I somehow suspect that your message that I replied to back in 1999
> was somehow more relevant? Yes? No?

Yes.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ 00/19] 3.10.1-stable review

[Darren Hart]

On Tue, 2013-07-16 at 18:37 -0700, Linus Torvalds wrote:
> On Tue, Jul 16, 2013 at 6:02 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> >>
> >> "Mauro, SHUT THE FUCK UP!"
> >
> > This one crosses the line.  There's no non-offensive way to tell a geek
> > "you are wrong", but this isn't even trying.  Bad Linus!
> 
> You know what? Not my proudest moment. I was really upset.

This goes a long way to resolving the stated issues in my opinion. Of
the three issues raised, Linus has either adequately justified himself
or conceded. This wasn't meant to be Linus on trial was it? :-)

I'm sure we could dig up a thousand more references of "bad" behavior
from others on LKML. Before we do let's first make sure the recipient is
not being "resistant to education" (a phrase I've picked up from Thomas
Gleixner and like very much) or has somehow provoked things. Ted Ts'o
will recall fondly all the pigs in guinea *smirk*.

I enjoy a good rant as much as anyone, but I recognize personal attacks
can be very harmful to the individual and possibly (difficult to prove)
the quality of the project. This is especially true when coming from
someone that is held in very high regard, such as Linus and the other
maintainers.

I think the one tangible TODO that has come out of this is to DOCUMENT
expectations. Paul Gortmaker has already submitted a netdev FAQ which I
have reviewed and David Miller approved of. I have committed to review
stable_kernel_rules. It appears there is also call to have Linus'
expectations of the maintainers documented. This would also be good for
everyone to read to better understand the responses they receive from
maintainers and why things are the way they are.

With that done, I think some tolerance in both directions would improve
things here. And as a last resort, we speak up when someone is under
attack.

"Whoa Nelly, calm down, don't forget your meds. Seriously though, that
(is not acceptable code|violates a core policy), see the following
documentation." This adds some burden on the broader audience to point
people at the docs, because even RTFM has to get annoying to repeat too
often.

And with that, I'll sign out of this thread unless anyone wants to
discuss documentation - but those should probably happen on LKML (or
maybe KS as some have suggested).

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Linus Torvalds]

On Tue, Jul 16, 2013 at 8:16 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Tue, 2013-07-16 at 20:02 -0700, Linus Torvalds wrote:
>>
>> Umm. Notice how the "Joseph" I replied to had deleted all the comments he wrote?
>
> Sorry, that completely escaped me.
>
>> That should tell you something. I smacked down a troll.
>>
>> If I was polite to you all those years ago, and I was polite but firm
>> in the two first responses, please give me credit for when I smack
>> somebody down. There may be a reason for it. The fact that the person
>> deleted his messages (or github deleted them for him - I have no idea
>> what their comment policy is) and you cannot see that context any more
>> online should not make you think that I suddenly went crazy.
>
> Unfortunately, it seems I'm not the only one to be confused by this.

Heh.

I think this one is a pretty extreme example (because the context
simply is no longer *there*), but the fact is, it's not uncommon.

People think I get all the credit (and hey, I do), but here's a
somewhat darker side to the story too. I get a lot of grief too, and
usually from people who don't have the context. In the blog you
posted, it was because the context simply wasn't there any more, but
let's be honest: even when the context is there, how many people read
it? It's a cesspool out there (*cough*slashdot*cough*).

And hey, I think Sarah's outburst itself was due to a similar "I know
Linus curses at people, and who cares about context, it's never
acceptable". Because I guarantee that it was *not* because of the
actual email she replied to, or anything I've written her. Feel free
to go back and check.

I'm really not complaining. It's part of my job, and I'm quite used to
it. This is not new. Certain people and places love to hate on Linus,
the egotistical ass. And hey, on the whole I can honestly say that I'm
*way* ahead. They aren't exactly wrong - it's not like I have a weak
ego. I get most annoyed when people say it's "new" and due to the
success of Linux. Dammit, I had a strong ego when I started this whole
thing, so don't try to chalk it all up to success.

Guys, I love my job. The kernel developer community is great. But I
suspect that some of you don't necessarily think about the other side.
I had slashdot discussing my abusive relationship with my wife and
kids thanks to Sarah's comments. Talk about having a thick skin -
trust me when I tell you that I get as well as I give out.

                 Linus

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Darren Hart]

On Tue, 2013-07-16 at 21:48 -0700, Linus Torvalds wrote:

> Guys, I love my job. The kernel developer community is great. But I
> suspect that some of you don't necessarily think about the other side.
> I had slashdot discussing my abusive relationship with my wife and
> kids thanks to Sarah's comments. Talk about having a thick skin -
> trust me when I tell you that I get as well as I give out.

That's awful. People suck. I stopped reading slashdot years ago for the
quality of the content and commentary, apparently it has not improved.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: [ 00/19] 3.10.1-stable review

[Sarah Sharp]

On Tue, Jul 16, 2013 at 03:12:45PM -0700, Linus Torvalds wrote:
> I react very strongly when somebody argues against fixing regressions.
> Let's just say that there's too many years of baggage that I carry
> around on that issue..
> 
> So that is definitely one of the things that make me go ballistic.
> Buggy code isn't actually one of them. Bugs happen. Even really stupid
> bugs happen, and happen to good people. They had a bad day, or it was
> just a brainfart.  Not that I will be _polite_ about bad code, mind
> you, and there might be some bad words in there, but it doesn't make
> me blow up.
> 
> Being cavalier about known regressions is definitely the primary
> trigger. I suspect there are others, but I can't seem to recall any
> other particular hot-button issues right now. Maybe Sarah can post a
> few more pointers..

Hmm... The only thing I can think of off the top of my head is that you
tend to hate it when someone puts the needs of their particular
architecture or distro at a higher priority than the needs of the kernel
community.  If they start to push crap code late in the merge window to
further their personal goals, you tend to blow up at them.  See the
'deep throat' comment on the PE binary signing thread, for instance.

The timing of when incidents happen also seems to effect whether you get
triggered.  I suspect most of the incidents of you "blowing up" at
people happen during the merge window.

Sarah Sharp

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Sarah Sharp]

On Tue, Jul 16, 2013 at 10:22:38PM -0700, Darren Hart wrote:
> On Tue, 2013-07-16 at 21:48 -0700, Linus Torvalds wrote:
> 
> > Guys, I love my job. The kernel developer community is great. But I
> > suspect that some of you don't necessarily think about the other side.
> > I had slashdot discussing my abusive relationship with my wife and
> > kids thanks to Sarah's comments. Talk about having a thick skin -
> > trust me when I tell you that I get as well as I give out.
> 
> That's awful. People suck. I stopped reading slashdot years ago for the
> quality of the content and commentary, apparently it has not improved.

Slashdot, Hacker News, and Reddit are all cesspools.  I would much
rather discuss this topic on LKML or at KS than wade through that muck.

Bah, let's settle this at KS, away from the court of public opinion.

Sarah Sharp

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Willy Tarreau]

On Tue, Jul 16, 2013 at 08:51:36PM -0400, Steven Rostedt wrote:
> On Wed, 2013-07-17 at 08:32 +0800, Jeff Liu wrote:
> 
> > Another thing might deviated from the main theme, but I'd like to raise it
> > here because I would like to see what's the proper way for that.
> > 
> > For instance, people A posted a patch set to the mailing list at first,
> > people B think that there are some issues in A's implementation, and he
> > happened to play around the same stuff recently, so he submitted another
> > patch series.  Finally, people B made it.
> > (In that period, people A kept silent, maybe because he/she was unhappy) 
> > 
> > This is a actual occurrence I once observed from a subsystem list(my
> > apologies, I just want to talk this case rather than against somebody),
> > it seems people A is a new comer(because I can not searched any past
> > commits of him/her from the git log), people B is definitely a senior guy.
> > 
> > So that's my question, is that a proper collaboration form in kernel
> > community?  Does it better if people B could give some suggestions to
> > help A to improve the code, especially if those help would help A stepping
> > into the kernel development -- maybe it's depend largely on one's opinion. :(
> 
> This is a completely different issue from the one in this thread, but it
> is also a legitimate issue and honestly, a bigger one than perceived
> insults.
> 
> Is it proper collaboration? Absolutely not. Something that I try to be
> sensitive to as it's something I can do as well. There's been things on
> my todo list, where someone would send me patches that do it. I would be
> thinking "darn it, I wanted to do it" and even worse, the patches that
> were sent wouldn't be of the way I wanted them. But I've tried to be
> good, and instead of just going about and implementing it myself, I
> would try to help the person massage the patches into what I wanted.
> That takes a lot of effort and discipline, and honestly, helping someone
> else do the work you wanted is much harder than just doing it yourself. 
> 
> Sometimes the maintainer just takes the easier route, and does the work
> themselves (because it's also more fun too). But that's really a slap in
> the face of the person that submitted the work in the first place. If
> anything hurts the community, it's this behavior. Not Linus giving
> someone an ass wipe.

I'm used to practice a workaround for this issue on another project. When
a newcomer sends me wrong code trying to address a real issue, I first
spend a little time helping him/her. If I see that the gap is too large
for him/her to adapt his/her work without too much help from me, then I
do the work myself, propose to him/her and once it's OK, and ask him/her
to submit the work with his/her name. That way they quickly gain trust
in themselves, more easily feel part of the community and get a clearer
idea of what is needed. Generally patches quality significantly improves
with this, in very short time, because they realize the gap is huge and
that they won't get this chance often.

My principle is to value the effort more than the result. If the first
author spent one week digging into the code to identify an issue and
came up with the wrong fix, and I can fix it in 5 minutes, he certainly
deserves all the merits for the work, not me.

I don't believe this is that much practiced on LKML. I know at least
one developer who does this, but he's probably the exception. I more
often see counter proposals just as if two authors were fighting to
get their patch merged.

Willy

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[James Bottomley]

On Tue, 2013-07-16 at 14:18 -0700, Paul E. McKenney wrote:
> On Tue, Jul 16, 2013 at 10:27:09PM +0400, James Bottomley wrote:
> > On Mon, 2013-07-15 at 15:38 -0700, Linus Torvalds wrote:
> > > On Mon, Jul 15, 2013 at 3:08 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > > >
> > > > Can we please make this into a Kernel Summit discussion. I highly doubt
> > > > we would solve anything, but it certainly would be a fun segment to
> > > > watch :-)
> > > 
> > > I think we should, because I think it's the kind of thing we really
> > > need at the KS - talking about "process".
> > 
> > Can you formulate the process issue to discuss?  I've heard "Linus needs
> > to yell less at people" and "the mailing lists need to be more
> > 'professional'" neither of which seems to identify an actual process.
> > Are we perhaps discussing guidelines for giving feedback on patches?
> > 
> > > At the same time, I really don't know what the format would possibly
> > > be like for it to really work as a reasonable discussion. And I think
> > > that is important, because this kind of subject is *not* likely
> > > possible in the traditional "people sit around tables and maybe
> > > somebody has a few slides" format.
> > 
> > > A small panel discussion with a few people (fiveish?) that have very
> > > different viewpoints, along with baskets of rotten fruit set out on
> > > the tables? That could be fun. And I'm serious, although we might want
> > > to limit the size of the fruit to smaller berries ;)
> > 
> > How about Lychees?  They're prickly on the outside, very wet on the
> > inside and have large stones ...
> 
> They taste good, too.
> 
> > But what are the viewpoints?  "maintainers need to yell more"?
> > "maintainers need to yell less"?  I don't think I agree with either.
> > I'm perfectly happy to run linux-scsi along reasonable standards of
> > civility and try to keep the debates technical, but that's far easier to
> > do on a low traffic list; obviously, I realise that style of argument
> > doesn't suit everyone, so it's not a standard of behaviour I'd like to
> > see universally imposed.  In fact, I've got to say that I wouldn't like
> > to see *any* behaviour standard imposed ... they're all basically cover
> > for power plays (or soon get abused as power plays); the only real way
> > to display leadership on behaviour standards is by example not by fiat.
> 
> OK, I am stupid enough to take a stab at this...
> 
> 1.	Does the Linux kernel community's health depend on the occasional
> 	rant?  [My guess is that we simply have no way of knowing.
> 	That said, I would be interested in hearing specific examples
> 	of open-source communities that are as doing as well as is the
> 	Linux community and that live within stricter social mores.
> 	Cue arguments about exactly what "doing well" means...]
> 
> 2.	Could the Linux kernel community's health be improved by banning
> 	the occasional rant?  [Again, I don't believe that we have any
> 	way of knowing.]
> 
> 3.	Is there some reasonable way to accommodate a wide range of
> 	styles of interaction within the Linux community?  [I hope that
> 	the answer is "yes", but it probably becomes impossible if you
> 	add the qualifier "that everyone is happy with".]
> 
> 4.	If there is some reasonable way to accommodate a wide range
> 	of styles of interaction within the Linux community, can this
> 	be done globally, or does this require that people who prefer a
> 	specific style confine themselves to portions of the community
> 	that practice that specific style?  [As I grow older, I become
> 	increasingly pessimistic about the possibility of keeping everyone
> 	happy, but who knows?]
> 
> For whatever it is worth...

Well, you have friends in acadaemia, perhaps there might be an
interesting study here.  If you consider the management style of the
kernel, does it enable contributions from a broader range of people than
would be tolerated in industry?  Industry has a problem with what
managers like to call "brilliant jerks" people who have a well
recognised talent but who cannot be controlled (at least by the
aforementioned managers) and become corrosive to the team (do we
actually manage to make use of these people in the kernel?).  They also
tend to have a problem at the bottom end: those who are just about OK at
their jobs; certainly not bad enough to be fired but whom they'd dearly
love to replace with better workers (does the attitude in the kernel
tend to discourage these types?)

It's probably less relevant to the discussion at hand, but I'd be
curious to see the results.  Assuming they say that we do have a higher
output per developer, the next study could investigate why this is ...

James

Re: [ 00/19] 3.10.1-stable review

[CAI Qian]

----- Original Message -----
> From: "Joe Perches" <joe@perches.com>
> To: "NeilBrown" <neilb@suse.de>
> Cc: "Steven Rostedt" <rostedt@goodmis.org>, "J. Bruce Fields" <bfields@fieldses.org>, "Linus Torvalds"
> <torvalds@linux-foundation.org>, "Sarah Sharp" <sarah.a.sharp@linux.intel.com>, "Ingo Molnar" <mingo@kernel.org>,
> "Guenter Roeck" <linux@roeck-us.net>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "Dave Jones"
> <davej@redhat.com>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "Andrew Morton"
> <akpm@linux-foundation.org>, "stable" <stable@vger.kernel.org>, "Darren Hart" <dvhart@linux.intel.com>
> Sent: Tuesday, July 16, 2013 7:50:52 AM
> Subject: Re: [ 00/19] 3.10.1-stable review
> 
> On Tue, 2013-07-16 at 09:42 +1000, NeilBrown wrote:
> > Being "polite" without being "nice" is quite possible.
> > It even has a name:  Diplomacy.
> 
> And we all know how circular/indirect/implied/useless
> some of those diplomatic conversations can be.
Modern human is more diplomatic than ancient barbarians. Will the trend
continue?
> 
> Just remember to bring a 'Big Stick' and don't be shy
> when it's necessary to display it.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[CAI Qian]

----- Original Message -----
> From: "Trond Myklebust" <Trond.Myklebust@netapp.com>
> To: "Ric Wheeler" <ricwheeler@gmail.com>
> Cc: "Sarah Sharp" <sarah.a.sharp@linux.intel.com>, "David Lang" <david@lang.hm>,
> ksummit-2013-discuss@lists.linuxfoundation.org, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "Darren Hart"
> <dvhart@linux.intel.com>, "Ingo Molnar" <mingo@kernel.org>, "Olivier Galibert" <galibert@pobox.com>, "Linux Kernel
> Mailing List" <linux-kernel@vger.kernel.org>, "stable" <stable@vger.kernel.org>, "Linus Torvalds"
> <torvalds@linux-foundation.org>, "Willy Tarreau" <w@1wt.eu>
> Sent: Wednesday, July 17, 2013 7:53:30 AM
> Subject: Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML
> 
> On Tue, 2013-07-16 at 19:31 -0400, Ric Wheeler wrote:
> > On 07/16/2013 07:12 PM, Sarah Sharp wrote:
> > > On Tue, Jul 16, 2013 at 06:54:59PM -0400, Steven Rostedt wrote:
> > >> On Tue, 2013-07-16 at 15:43 -0700, Sarah Sharp wrote:
> > >>
> > >>> Yes, that's true.  Some kernel developers are better at moderating
> > >>> their
> > >>> comments and tone towards individuals who are "sensitive".  Others
> > >>> simply don't give a shit.  So we need to figure out how to meet
> > >>> somewhere in the middle, in order to establish a baseline of civility.
> > >> I have to ask this because I'm thick, and don't really understand,
> > >> but ...
> > >>
> > >> What problem exactly are we trying to solve here?
> > > Personal attacks are not cool Steve.  Some people simply don't care if a
> > > verbal tirade is directed at them.  Others do not want anyone to attack
> > > them personally, but they're fine with people attacking their code.
> > >
> > > Bystanders that don't understand the kernel community structure are
> > > discouraged from contributing because they don't want to be verbally
> > > abused, and they really don't want to see either personal attacks or
> > > intense belittling, demeaning comments about code.
> > >
> > > In order to make our community better, we need to figure out where the
> > > baseline of "good" behavior is.  We need to define what behavior we want
> > > from both maintainers and patch submitters.  E.g. "No regressions" and
> > > "don't break userspace" and "no personal attacks".  That needs to be
> > > written down somewhere, and it isn't.  If it's documented somewhere,
> > > point me to the file in Documentation.  Hint: it's not there.
> > >
> > > That is the problem.
> > >
> > > Sarah Sharp
> > 
> > The problem you are pointing out - and it is a problem - makes us less
> > effective
> > as a community.
> 
> Not really. Most of the people who already work as part of this
> community are completely used to it. We've created the environment, and
> have no problems with it.
> 
> Where it could possibly be a problem is when it comes to recruiting
> _new_ members to our community. Particularly so given that some
> journalists take a special pleasure in reporting particularly juicy
> comments and antics. That would tend to scare off a lot of gun-shy
> newbies.
> On the other hand, it might tend to bias our recruitment toward people
> of a more "special" disposition. Perhaps we finally need the services of
> a social scientist to help us find out...
Does that sound like there are not going to have enough direct/thick skin
new kernel developers around to maintain the future Linux community? Maybe
just need a better pipeline for people comfortable for this culture?
> 
> --
> Trond Myklebust
> Linux NFS client maintainer
> 
> NetApp
> Trond.Myklebust@netapp.com
> www.netapp.com
> N�����r��y���b�X��ǧv�^�)޺{.n�+������z)���w*jg��������ݢj/���z�ޖ��2�ޙ���&�)ߡ�a��\x7f���G���h��j:+v���w�٥

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Dan Carpenter]

On Mon, Jul 15, 2013 at 04:15:55PM -0700, Guenter Roeck wrote:
> "Your code breaks the build for every platform. Would you please kindly
> consider fixing it ?"

Something like this: https://lists.launchpad.net/ac100/msg01040.html

"small typo here."

Marc, was obviously dripping with sarcasm when he wrote that, but it
was completely lost on the patch submitter.  I've done that too
where I asked "Are you sure you want to call schedule() while
holding a spinlock()?"  It ended up becoming flame fest and it could
have been avoided if I had said, "You are not allowed to call
shedule() while holding a spinlock."

Also instead of saying "Your code is crap", I prefer to say "This
patch is crap."  I suspect the submitters secretly know I think they
are crap too along with their code, but it's important to maintain
the facade.  :)

One other thing which is tricky is if there is someone whose patches
are so worthless it's just a waste of time.  There have been a
couple times where I've told people to stop submitting patches until
they have a few more years of programming experience.

regards,
dan carpenter

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Dan Carpenter]

On Tue, Jul 16, 2013 at 04:49:27PM +0100, Stefano Stabellini wrote:
> The etiquette on the lkml is by far the roughest of them all. It's the
> "bad neighborhood with guns" of the Open Source world. You never know
> when you are going to get a bullet, but sooner or later you'll get one.

Only Andrew Morton actually reads LKML.  These days kernel dev work
takes place on subsystem lists.  I wonder if some mailing lists are
worse than others?  From what I have seen people are mostly civil.

regards,
dan carpenter

Re: [ 00/19] 3.10.1-stable review

[Janne Karhunen]

On Mon, Jul 15, 2013 at 9:17 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:

>
> Google "management by perkele".

Actually, not even our former president mr. Kekkonen never went quite
as far using this method. I think something along the lines of
legendary 'saatanan tunarit' would suffice next time :)


--
Janne

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Jeff Liu]

On 07/17/2013 08:51 AM, Steven Rostedt wrote:

> On Wed, 2013-07-17 at 08:32 +0800, Jeff Liu wrote:
> 
>> Another thing might deviated from the main theme, but I'd like to raise it
>> here because I would like to see what's the proper way for that.
>>
>> For instance, people A posted a patch set to the mailing list at first,
>> people B think that there are some issues in A's implementation, and he
>> happened to play around the same stuff recently, so he submitted another
>> patch series.  Finally, people B made it.
>> (In that period, people A kept silent, maybe because he/she was unhappy) 
>>
>> This is a actual occurrence I once observed from a subsystem list(my
>> apologies, I just want to talk this case rather than against somebody),
>> it seems people A is a new comer(because I can not searched any past
>> commits of him/her from the git log), people B is definitely a senior guy.
>>
>> So that's my question, is that a proper collaboration form in kernel
>> community?  Does it better if people B could give some suggestions to
>> help A to improve the code, especially if those help would help A stepping
>> into the kernel development -- maybe it's depend largely on one's opinion. :(
> 
> This is a completely different issue from the one in this thread, but it
> is also a legitimate issue and honestly, a bigger one than perceived
> insults.
> 
> Is it proper collaboration? Absolutely not. Something that I try to be
> sensitive to as it's something I can do as well. There's been things on
> my todo list, where someone would send me patches that do it. I would be
> thinking "darn it, I wanted to do it" and even worse, the patches that
> were sent wouldn't be of the way I wanted them. But I've tried to be
> good, and instead of just going about and implementing it myself, I
> would try to help the person massage the patches into what I wanted.

It's kind of you. Generally, most forks are nice enough in helping others.
Actually, I only noticed once of something like that the year before.
Well, I just received an offline email from my college a fews hours ago as
she checked this topic and unfortunately, she has experienced the same thing
a few days ago.

> That takes a lot of effort and discipline, and honestly, helping someone
> else do the work you wanted is much harder than just doing it yourself. 

Exactly, so I always appreciate the patch reviewers.

Thanks,
-Jeff

> 
> Sometimes the maintainer just takes the easier route, and does the work
> themselves (because it's also more fun too). But that's really a slap in
> the face of the person that submitted the work in the first place. If
> anything hurts the community, it's this behavior. Not Linus giving
> someone an ass wipe.
> 
> -- Steve
>  
> 

Re: [ATTEND] How to act on LKML

[Stefano Stabellini]

On Tue, 16 Jul 2013, H. Peter Anvin wrote:
> On 07/16/2013 09:58 AM, Stefano Stabellini wrote:
> > 
> > Because Linux is the most widely used kernel, it's everywhere from
> > embedded devices to supercomputers.
> > Many different companies make a business on Linux and pay people to work
> > on it (not FreeBSD or NetBSD). But that's different from what I was
> > saying below. Also not all the sub-groups within the kernel development
> > circles work this way.
> > 
> 
> I think you have an inverse causal relationship here.
> 
> Linux took off in a way that the other OSS operating systems didn't, and
> several of them had started earlier and with way more funding available.
> 
> You really have to think about why we are not running Hurd, or any of
> the various *BSDs, and instead Linus' "not big and professional like
> GNU" hack.  In my opinion it was because the Linux community was in fact
> the most open and welcoming of the Open Source communities around.

Then it's the time to ask ourselves: is it still like this?


> > When HPA wrote "I find it utterly impossible to be offended by it", that
> > might be true for Linus' rants and I also find them humorous sometimes.
> > But unfortunately this kind of behavior is by no means limited to Linus
> > and it's easy to misunderstand, especially when you don't know the
> > person.
> 
> There seem to be a fair number of people who think they can imitate
> Linus' style but do so without understanding the subtle aspects about
> how to apply it.

Right, this is actually the main point I wanted to make.
Linus' outbursts are not the problem per se because Linus tends to
attack the code rather than the people and does so when he has a point,
without straying from the conversation.
However they set up an example that others try to imitate, without the
same thoughtfulness.
I guess this is the price to pay for being a role model ;-)

Re: [ATTEND] How to act on LKML

[Stefano Stabellini]

On Wed, 17 Jul 2013, Jiri Kosina wrote:
> On Tue, 16 Jul 2013, Stefano Stabellini wrote:
> 
> > > > I think that it's hurting Linux and in particular it's hurting
> > > > attracting new talents.
> > > 
> > > Then why do we have the largest # of developers than any other Open
> > > Source project?
> > 
> > Because Linux is the most widely used kernel, it's everywhere from
> > embedded devices to supercomputers.
> 
> And that's because ... ?
> 
> Yes, because the community has been very open since its very beginning 
> (and this is not "being open about why I hate you personally", but this is 
> "being open about what I think about your code").

Being open about what I think about your code doesn't mean that I can
feel free to verbally attack you.


> Plus there is a *LOT* of humor and sarcasm in all that. Which just 
> contributes to working on linux kernel being fun. I'd absolutely like to 
> keep that spirit.
> 
> If you guys now start telling others what is allowed and what is forbidden 
> to say, you are going to destroy this completely.
> 
> I don't want to be a part of a community where you have to read a legal 
> code before you can speak without fear of being accused of verbal 
> violence.
> 
> This just doesn't fit into how people of my culture see the world; hence, 
> I may even feel offended by Sarah's proposal (i.e. being very restrictive 
> about what I am allowed to say), actually. I like openness, I like 
> sarcasm, I like fun. Anyone who is trying to forbid this just doesn't fit 
> into my culture.

We should be able to prevent verbal abuses without involving legal,
right?
Would a NETIQUETTE file be enough, or would you consider that "legal
code"?


> > > Honestly, I think LKML over the years has become more tame. Yeah, back
> > > in 2005 it was rather harsh, but I don't really see that anymore. I
> > > don't see the nasty flame wars going on. Everything seems to be focused
> > > more on the technical side, and there's really very little personal
> > > attacks out there. Sure, with 15,000 emails a month, you get a few. And
> > > Linus will get fed up and burst. But they are really few and far
> > > between. And sometimes, a Linus burst gets things moving along much
> > > faster than being "professional". You think ARM would have gotten their
> > > act together as quick as they did if Linus didn't curse them out and
> > > threaten to stop pulling their crap?
> >  
> > I think there is a way to get the point across without cursing.
> 
> Maybe there is, maybe there is not.
> 
> I am not cursing in my e-mails, you are probably neither. Linus is. Others 
> are.
> 
> So what? He/they believe they achieves their goal through that mode of 
> operation (and very often they indeed do), as so do we, through different 
> means of communication.
> 
> No need to change anything anywhere. Please let everyone express their 
> feelings the way the believe it's best for achieving their goals, and do 
> the same.

There is a very fine line between cursing and what people might perceive
as a personal attack.

Re: [ATTEND] How to act on LKML

[Ramkumar Ramachandra]

Sarah Sharp wrote:
> I do smile often in email. :)  And be sad. :( And be apologetic. :-/
> Smug. ^~^  Angry. >:[  Sarcastic. ;)  Trolling/crazy. 8)  D'oh. (>.<)
> Worried. (>_>);  Disappointed. (-_-)  Kitty! =^_^=  Meow!
>
> Be creative.  There are ways of expressing emotion without cussing.

Personally, I think the whole issue of swearing on-list is taken way
too seriously [1].  There are many ways of expressing emotion;
considering one such form "unprofessional" is just a form of
suffocation.  Members of the mailing list automatically pick up on the
influential styles (i.e. the styles of the active participants and
effective communicators).  If you think your style is "better",
there's exactly one way to verify the claim: you participate actively;
your style will automatically rub off on the others if it is shown to
be effective.

[1]: http://youtu.be/7raS7hmLkAA

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[James Bottomley]

On Wed, 2013-07-17 at 17:15 +0800, Jeff Liu wrote:
> On 07/17/2013 08:51 AM, Steven Rostedt wrote:
> 
> > On Wed, 2013-07-17 at 08:32 +0800, Jeff Liu wrote:
> > 
> >> Another thing might deviated from the main theme, but I'd like to raise it
> >> here because I would like to see what's the proper way for that.
> >>
> >> For instance, people A posted a patch set to the mailing list at first,
> >> people B think that there are some issues in A's implementation, and he
> >> happened to play around the same stuff recently, so he submitted another
> >> patch series.  Finally, people B made it.
> >> (In that period, people A kept silent, maybe because he/she was unhappy) 
> >>
> >> This is a actual occurrence I once observed from a subsystem list(my
> >> apologies, I just want to talk this case rather than against somebody),
> >> it seems people A is a new comer(because I can not searched any past
> >> commits of him/her from the git log), people B is definitely a senior guy.
> >>
> >> So that's my question, is that a proper collaboration form in kernel
> >> community?  Does it better if people B could give some suggestions to
> >> help A to improve the code, especially if those help would help A stepping
> >> into the kernel development -- maybe it's depend largely on one's opinion. :(
> > 
> > This is a completely different issue from the one in this thread, but it
> > is also a legitimate issue and honestly, a bigger one than perceived
> > insults.
> > 
> > Is it proper collaboration? Absolutely not. Something that I try to be
> > sensitive to as it's something I can do as well. There's been things on
> > my todo list, where someone would send me patches that do it. I would be
> > thinking "darn it, I wanted to do it" and even worse, the patches that
> > were sent wouldn't be of the way I wanted them. But I've tried to be
> > good, and instead of just going about and implementing it myself, I
> > would try to help the person massage the patches into what I wanted.
> 
> It's kind of you. Generally, most forks are nice enough in helping others.
> Actually, I only noticed once of something like that the year before.
> Well, I just received an offline email from my college a fews hours ago as
> she checked this topic and unfortunately, she has experienced the same thing
> a few days ago.

If you want a quiet investigation, I or one of the other maintainers can
do it offline (you'll need to send the details via private email). Just
for your information, though, I've done this sort of thing before too.
This is probably the most egregious example:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2908d778ab3e244900c310974e1fc1c69066e450

James

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Jeff Liu]

On 07/17/2013 06:58 PM, James Bottomley wrote:

> On Wed, 2013-07-17 at 17:15 +0800, Jeff Liu wrote:
>> On 07/17/2013 08:51 AM, Steven Rostedt wrote:
>>
>>> On Wed, 2013-07-17 at 08:32 +0800, Jeff Liu wrote:
>>>
>>>> Another thing might deviated from the main theme, but I'd like to raise it
>>>> here because I would like to see what's the proper way for that.
>>>>
>>>> For instance, people A posted a patch set to the mailing list at first,
>>>> people B think that there are some issues in A's implementation, and he
>>>> happened to play around the same stuff recently, so he submitted another
>>>> patch series.  Finally, people B made it.
>>>> (In that period, people A kept silent, maybe because he/she was unhappy) 
>>>>
>>>> This is a actual occurrence I once observed from a subsystem list(my
>>>> apologies, I just want to talk this case rather than against somebody),
>>>> it seems people A is a new comer(because I can not searched any past
>>>> commits of him/her from the git log), people B is definitely a senior guy.
>>>>
>>>> So that's my question, is that a proper collaboration form in kernel
>>>> community?  Does it better if people B could give some suggestions to
>>>> help A to improve the code, especially if those help would help A stepping
>>>> into the kernel development -- maybe it's depend largely on one's opinion. :(
>>>
>>> This is a completely different issue from the one in this thread, but it
>>> is also a legitimate issue and honestly, a bigger one than perceived
>>> insults.
>>>
>>> Is it proper collaboration? Absolutely not. Something that I try to be
>>> sensitive to as it's something I can do as well. There's been things on
>>> my todo list, where someone would send me patches that do it. I would be
>>> thinking "darn it, I wanted to do it" and even worse, the patches that
>>> were sent wouldn't be of the way I wanted them. But I've tried to be
>>> good, and instead of just going about and implementing it myself, I
>>> would try to help the person massage the patches into what I wanted.
>>
>> It's kind of you. Generally, most forks are nice enough in helping others.
>> Actually, I only noticed once of something like that the year before.
>> Well, I just received an offline email from my college a fews hours ago as
>> she checked this topic and unfortunately, she has experienced the same thing
>> a few days ago.
> 
> If you want a quiet investigation, I or one of the other maintainers can
> do it offline (you'll need to send the details via private email). Just
> for your information, though, I've done this sort of thing before too.
> This is probably the most egregious example:

I'll send out those info for your investigation in a little while.

Thanks,
-Jeff

 

Re: [ATTEND] How to act on LKML

[Geert Uytterhoeven]

On Tue, Jul 16, 2013 at 7:16 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> I have two teenage daughters. I've never heard them curse at all, and
> I'm not sure my oldest ever has. From a young age, I taught them that I
> don't care what they hear, it's what they say that counts. I never
> sheltered them from "curse" words. I taught them that curse words are
> for when you really need to make a point and want everyone to listen to
> you because you are really upset. The less you use them, the more impact
> they have when you do. They took this to heart, and are saving it up for
> when something big happens, because I can't get them to curse even when
> I try :-)

Oh no, they've already signed up for an I-save-my-cursery-for-something-big
membership ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Steven Rostedt]

On Wed, 2013-07-17 at 07:51 +0200, Willy Tarreau wrote:

> I don't believe this is that much practiced on LKML. I know at least
> one developer who does this, but he's probably the exception. I more
> often see counter proposals just as if two authors were fighting to
> get their patch merged.

And getting cursed out on LKML is also the exception and not the rule.
But it's the bad apples that seem to stand out. People say how horrible
LKML is, but as mentioned in the thread, Slashdot is a much worse place
to post than LKML. The difference with LKML is that you may deserve the
cursing you get.

-- Steve

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Ricardo Ferreira]

Slashdot is just a cesspool of trolls, not a good comparison.


On 17 July 2013 13:21, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Wed, 2013-07-17 at 07:51 +0200, Willy Tarreau wrote:
>
> > I don't believe this is that much practiced on LKML. I know at least
> > one developer who does this, but he's probably the exception. I more
> > often see counter proposals just as if two authors were fighting to
> > get their patch merged.
>
> And getting cursed out on LKML is also the exception and not the rule.
> But it's the bad apples that seem to stand out. People say how horrible
> LKML is, but as mentioned in the thread, Slashdot is a much worse place
> to post than LKML. The difference with LKML is that you may deserve the
> cursing you get.
>
> -- Steve
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [ATTEND] How to act on LKML

[Al Viro]

On Wed, Jul 17, 2013 at 10:38:55AM +0100, Stefano Stabellini wrote:

> There is a very fine line between cursing and what people might perceive
> as a personal attack.

I wanted to stay out of that thread, but that argument really goes over
the top.  Look, ANYTHING might be perceived as a personal attack by
somebody.  I have seen a turd that really perceived a girl solving a math
problem faster than he managed to do that as a severe personal attack.
How about "student so-and-so is getting consistently better grades"?
Treated as a personal attack.  Rationale: "spoils the grades for the
rest of the group".  Or "professor so-and-so goes into hard stuff; sure,
it might make the course more interesting for some weirdos, but what of
those who don't need all that shit and simply want their B?"

What, you don't consider those "people"?  How exclusionary of you....
Sorry, they *are* members of our species.  And not particulary rare,
at that.

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Steven Rostedt]

On Wed, 2013-07-17 at 13:30 +0100, Ricardo Ferreira wrote:
> Slashdot is just a cesspool of trolls, not a good comparison.

Point taken.

I posted this privately, and I think I'll repost it here. I need to
modify it a bit as it wasn't meant to be public.


When I started sending patches to LKML it was not the cursing I was
afraid of, it was the possibility of top notch developers pointing out
my flaws. Linux is intimidating not because it can be harsh, but because
its the big league. You are posting code not only to the world but also
to some of the best programmers on the planet, and frankly, that's
really scary. And I think that's the real reason people who are shy tend
not to want to participate. They use the harshness of LKML as an excuse,
but I think it's really that they may be insecure about their own work
and how it will compare with the best of the best.

Both my wife and I have done karate for decades. My wife has even won a
national tournament. She can do demos without a problem, but when she
has to get up in front of other top black belts, she's a nervous wreck.
She's her biggest critic, but she tends to know that when performing in
front of people as good as she is, or better, they can see her flaws as
much as she can. That is intimidating.

The point I'm making is that we need to find out what is preventing good
developers from joining the Linux community. Is it really the harshness
of the project, or is it because we expect you to have the best code,
and you will not be accepted if you are not that good. And I do not want
people joining that are not good programmers.

The answer is not to bash Linus into being a nice guy (which seems to be
what Sarah's trying to do), but we can get mentors or even "scouts" to
look for people of talent and help them get into the community. What
those people need is not a nicer LKML that will let mediocre developers
in, but someone that recognizes their talent and encourages them to
join, by reinforcing to them how good of a developer they are. I've
helped people this way. Talented programmers that were unsure of
themselves, and they have done extremely well in our community.

-- Steve

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Willy Tarreau]

On Wed, Jul 17, 2013 at 09:03:35AM -0400, Steven Rostedt wrote:
> On Wed, 2013-07-17 at 13:30 +0100, Ricardo Ferreira wrote:
> > Slashdot is just a cesspool of trolls, not a good comparison.
> 
> Point taken.
> 
> I posted this privately, and I think I'll repost it here. I need to
> modify it a bit as it wasn't meant to be public.
> 
> 
> When I started sending patches to LKML it was not the cursing I was
> afraid of, it was the possibility of top notch developers pointing out
> my flaws. Linux is intimidating not because it can be harsh, but because
> its the big league. You are posting code not only to the world but also
> to some of the best programmers on the planet, and frankly, that's
> really scary. And I think that's the real reason people who are shy tend
> not to want to participate. They use the harshness of LKML as an excuse,
> but I think it's really that they may be insecure about their own work
> and how it will compare with the best of the best.
> 
> Both my wife and I have done karate for decades. My wife has even won a
> national tournament. She can do demos without a problem, but when she
> has to get up in front of other top black belts, she's a nervous wreck.
> She's her biggest critic, but she tends to know that when performing in
> front of people as good as she is, or better, they can see her flaws as
> much as she can. That is intimidating.
> 
> The point I'm making is that we need to find out what is preventing good
> developers from joining the Linux community. Is it really the harshness
> of the project, or is it because we expect you to have the best code,
> and you will not be accepted if you are not that good. And I do not want
> people joining that are not good programmers.
> 
> The answer is not to bash Linus into being a nice guy (which seems to be
> what Sarah's trying to do), but we can get mentors or even "scouts" to
> look for people of talent and help them get into the community. What
> those people need is not a nicer LKML that will let mediocre developers
> in, but someone that recognizes their talent and encourages them to
> join, by reinforcing to them how good of a developer they are. I've
> helped people this way. Talented programmers that were unsure of
> themselves, and they have done extremely well in our community.

+1

Willy

Re: [ATTEND] How to act on LKML

[Felipe Contreras]

On Wed, Jul 17, 2013 at 4:17 AM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 16 Jul 2013, H. Peter Anvin wrote:

>> Linux took off in a way that the other OSS operating systems didn't, and
>> several of them had started earlier and with way more funding available.
>>
>> You really have to think about why we are not running Hurd, or any of
>> the various *BSDs, and instead Linus' "not big and professional like
>> GNU" hack.  In my opinion it was because the Linux community was in fact
>> the most open and welcoming of the Open Source communities around.
>
> Then it's the time to ask ourselves: is it still like this?

Yes it is. Linux is the only project I'm aware of where I know my
patches will be accepted if they are technically good, despite any
personal bullshit, not even Git allows this.

The fact that one can be open and honest, and discussion is welcome
(as long as it's constructive), in this list is one of the reasons why
Linux is so successful.

To me, Linux is an oasis among a desert of open source projects where
technical merit is not as important as "being nice", and that's why
those projects rot and eventually fork, and Linux would not.

I know you think "being nice" is better, but do you actually have any
evidence for this, or is it just wishful thinking? If you don't have
hard evidence, then I'd say you have to admit it's simply your
opinion, and I don't think the most successful software project in
history should change one if it's core principles simply because *you*
think it should.

Cheers.

-- 
Felipe Contreras

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Paul Gortmaker]

On 13-07-16 07:38 PM, Steven Rostedt wrote:
> On Tue, 2013-07-16 at 16:12 -0700, Sarah Sharp wrote:
> 

[...]

> 
>>   We need to define what behavior we want
>> from both maintainers and patch submitters.  E.g. "No regressions" and
>> "don't break userspace"
> 
> Yes, those do need to be documented.

Actually, they are already documented. See "Regressions" section in the
file Documentation/development-process/4.Coding

Paul.
--

> 
> 
>>  and "no personal attacks".
> 
> I actually disagree with this. What I would say this instead: "try to
> keep it technical and focus on the code. If you are upset at someone,
> think twice before hitting send. But if you really think this is the
> only way to deal with the situation, then that's your call, and you get
> to deal with the consequences."
> 
> I don't think changing peoples behavior is going to work. It wont. You
> don't want to change who you are, others don't want to change who they
> are. Deal with it. But what we can do is just try to educate people on
> what policies are needed to be a maintainer and code submitter (there is
> documentation already on some of this), and then point it to people. If
> people continue to ignore those after being shown, then yes, personal
> attacks are then in order.
> 
> 
>>   That needs to be
>> written down somewhere, and it isn't.  If it's documented somewhere,
>> point me to the file in Documentation.  Hint: it's not there.
> 
> Well, SubmittingPatches is there, but we should have a MaintainerRules
> or something.
> 
>>
>> That is the problem.
> 
> We can always use better documentation.
> 
> -- Steve
> 
> 
> _______________________________________________
> Ksummit-2013-discuss mailing list
> Ksummit-2013-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-2013-discuss
> 
> 

Re: [ATTEND] How to act on LKML

[Felipe Contreras]

On Tue, Jul 16, 2013 at 8:02 PM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:

> I've provided examples and personal stories in an attempt to give
> incentive to change.

Those are just stories; things that happened. What you need to provide
is *evidence* that if the community changes, things will be better,
and unless you have a study of series of collaborative groups like the
Linux kernel, that demonstrates that suppressing swearing has a
positive effect in the community, I'd say all you have is an
*opinion*.

> I cannot force on anyone the will to change, nor
> would I want to.  I cannot "manage" change in others.  I can only
> politely point out that the current community behavior does hurt other
> people, and keep people from contributing.

Which people have been hurt? Mauro? I would like to hear that from
him. Another recipient of your stories was Rafael, and he already said
he didn't feel personally attacked. I have also been a recipient of
Linus' cursing, and I don't see any reason to change.

But the more important question is; was the cursing justified? In the
case of Mauro, it most definitely was, because as Linus mentioned; he
broke the #1 rule of Linux, and that can't be tolerated from a
lieutenant.

So no, your stories don't prove that any people were hurt, justified
or not. But even that is not important, what is important is; was the
*project* hurt? I'd say you would need more than a couple of stories
to prove that.

> I'm not demanding change.  I'm merely asking to discuss the possibly of
> change at KS.

Everything is possible, the question is not "*can* it change", the
question is "*should* it change". And again, you need evidence to show
that it should.

Cheers.

-- 
Felipe Contreras

Re: [ATTEND] How to act on LKML

[Sarah Sharp]

On Wed, Jul 17, 2013 at 09:01:02AM -0500, Felipe Contreras wrote:
> I know you think "being nice" is better, but do you actually have any
> evidence for this, or is it just wishful thinking? If you don't have
> hard evidence, then I'd say you have to admit it's simply your
> opinion, and I don't think the most successful software project in
> history should change one if it's core principles simply because *you*
> think it should.

I haven't shared any "hard evidence" that civility works better in open
source projects, because to do so would be to bring gender politics into
the equation.  I don't want to make this into a gendered issue, but
since you want hard numbers, I will.

Go look at Dreamwidth, the open source Livejournal fork.  It has a good
code of conduct, so developers are civil to each other.  They encourage
all patch submissions, and take the time to work with people who don't
understand their community rules.

The result: 75% of their developers are women.  If you give a flying
fuck about diversity, and want to attract women to your open source
project, your developers need to be civil, and not verbally abuse each
other.

Sarah Sharp

Re: [ATTEND] How to act on LKML

[Willy Tarreau]

On Wed, Jul 17, 2013 at 07:40:43AM -0700, Sarah Sharp wrote:
> Go look at Dreamwidth, the open source Livejournal fork.  It has a good
> code of conduct, so developers are civil to each other.  They encourage
> all patch submissions, and take the time to work with people who don't
> understand their community rules.
> 
> The result: 75% of their developers are women.  If you give a flying
> fuck about diversity, and want to attract women to your open source
> project, your developers need to be civil, and not verbally abuse each
> other.

But this has nothing to do with a project's success or quality, gender
is not related. Are you suggesting that with more women the Linux kernel
would be a more successful project ? If so I think you're a bit biased.
In my opinion, only its good people make it a good project, whatever
their gender.

Willy

Re: [ATTEND] How to act on LKML

[Kurt H Maier]

On Wed, Jul 17, 2013 at 07:40:43AM -0700, Sarah Sharp wrote:
> 
> The result: 75% of their developers are women.  If you give a flying
> fuck about diversity, and want to attract women to your open source
> project, your developers need to be civil, and not verbally abuse each
> other.
> 

I object to your sexist implicit assertion that women are incapable of
dealing with differing approaches to interpersonal communication.  

khm

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Sarah Sharp]

On Wed, Jul 17, 2013 at 03:36:36AM -0400, CAI Qian wrote:
> > On Tue, 2013-07-16 at 19:31 -0400, Ric Wheeler wrote:
> > > On 07/16/2013 07:12 PM, Sarah Sharp wrote:
> > > > On Tue, Jul 16, 2013 at 06:54:59PM -0400, Steven Rostedt wrote:
> > > >> On Tue, 2013-07-16 at 15:43 -0700, Sarah Sharp wrote:
> > > > In order to make our community better, we need to figure out where the
> > > > baseline of "good" behavior is.  We need to define what behavior we want
> > > > from both maintainers and patch submitters.  E.g. "No regressions" and
> > > > "don't break userspace" and "no personal attacks".  That needs to be
> > > > written down somewhere, and it isn't.  If it's documented somewhere,
> > > > point me to the file in Documentation.  Hint: it's not there.
> > > >
> > > > That is the problem.
> > > >
> > > > Sarah Sharp
> > > 
> > > The problem you are pointing out - and it is a problem - makes us less
> > > effective
> > > as a community.
> > 
> > Not really. Most of the people who already work as part of this
> > community are completely used to it. We've created the environment, and
> > have no problems with it.
> > 
> > Where it could possibly be a problem is when it comes to recruiting
> > _new_ members to our community. Particularly so given that some
> > journalists take a special pleasure in reporting particularly juicy
> > comments and antics. That would tend to scare off a lot of gun-shy
> > newbies.
> >
> > On the other hand, it might tend to bias our recruitment toward people
> > of a more "special" disposition. Perhaps we finally need the services of
> > a social scientist to help us find out...
>
> Does that sound like there are not going to have enough direct/thick skin
> new kernel developers around to maintain the future Linux community? Maybe
> just need a better pipeline for people comfortable for this culture?

No, we don't need a better pipeline for people who can "put up with
shit".  We need a better pipeline for people who can work together
civilly, and still get shit done.

I'm working on getting a pipeline of women into kernel development,
through the FOSS Outreach Program for Women.  They slowly get introduced
to Linux development culture, starting with a very friendly separate
mailing list and IRC channel, and finally moving to work with a kernel
mentor on a bigger project on the main Linux kernel development lists.
We have seven women participating this round, and I suspect we'll have
even more the next round.

So deal with it.  You're going to have a lot more women in the kernel
community, and not all of them will be willing to put up with verbal
abuse.  If you want to attract top talent that also happen to be women
or racial minorities, the verbal abuse needs to stop.

Sarah Sharp

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Sarah Sharp]

On Wed, Jul 17, 2013 at 09:03:35AM -0400, Steven Rostedt wrote:
> The point I'm making is that we need to find out what is preventing good
> developers from joining the Linux community. Is it really the harshness
> of the project, or is it because we expect you to have the best code,
> and you will not be accepted if you are not that good. And I do not want
> people joining that are not good programmers.

Or does our documentation for getting new developers on board suck?  Or
do we simply need to have more mentors to help newcomers move from their
first checkpatch cleanup patch to larger projects?  Or do minorities
simply choose not to participate, because they see homophobic emails
like the 'deep throat' email, and decide they're likely to face racism
or sexism on the mailing list as well?

There are a lot of reasons newcomers don't want to join, or don't feel
they can join.  Unless we did some sort of survey to ask why people
don't participate, we won't know why they aren't.

Oh, BTW, someone did do an informal survey on why people do or don't
contribute to open source project.  They gave a talk at Open Source
Bridge entitled, "No, I won't contribute to your OS project".  You can
see the results of her poll, and her talk here:

https://www.zotero.org/groups/obridge_2013_os_contrib
https://www.dropbox.com/s/c6vjtx1zcdzejgw/foss_contributions.pdf

> The answer is not to bash Linus into being a nice guy (which seems to be
> what Sarah's trying to do), but we can get mentors or even "scouts" to
> look for people of talent and help them get into the community. What
> those people need is not a nicer LKML that will let mediocre developers
> in, but someone that recognizes their talent and encourages them to
> join, by reinforcing to them how good of a developer they are. I've
> helped people this way. Talented programmers that were unsure of
> themselves, and they have done extremely well in our community.

Are you volunteering to be a mentor for the FOSS Outreach Program for
Women? ;)  I will happily take more mentors for the next round in
November!

http://kernelnewbies.org/OPWIntro

Sarah Sharp

Re: [ATTEND] How to act on LKML

[Anca Emanuel]

Sarah Sharp: ok, the obvious: there are trolls, and some of them got to you.
They are and will try to make you a troll also. ( the evil come to you
with "good" intentions )

My advice: stick to technical problems.
You are used to start an flamewar.


On Wed, Jul 17, 2013 at 5:40 PM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
> On Wed, Jul 17, 2013 at 09:01:02AM -0500, Felipe Contreras wrote:
>> I know you think "being nice" is better, but do you actually have any
>> evidence for this, or is it just wishful thinking? If you don't have
>> hard evidence, then I'd say you have to admit it's simply your
>> opinion, and I don't think the most successful software project in
>> history should change one if it's core principles simply because *you*
>> think it should.
>
> I haven't shared any "hard evidence" that civility works better in open
> source projects, because to do so would be to bring gender politics into
> the equation.  I don't want to make this into a gendered issue, but
> since you want hard numbers, I will.
>
> Go look at Dreamwidth, the open source Livejournal fork.  It has a good
> code of conduct, so developers are civil to each other.  They encourage
> all patch submissions, and take the time to work with people who don't
> understand their community rules.
>
> The result: 75% of their developers are women.  If you give a flying
> fuck about diversity, and want to attract women to your open source
> project, your developers need to be civil, and not verbally abuse each
> other.
>
> Sarah Sharp
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Steven Rostedt]

On Wed, 2013-07-17 at 07:48 -0700, Sarah Sharp wrote:

> > Does that sound like there are not going to have enough direct/thick skin
> > new kernel developers around to maintain the future Linux community? Maybe
> > just need a better pipeline for people comfortable for this culture?
> 
> No, we don't need a better pipeline for people who can "put up with
> shit".  We need a better pipeline for people who can work together
> civilly, and still get shit done.
> 
> I'm working on getting a pipeline of women into kernel development,
> through the FOSS Outreach Program for Women.  They slowly get introduced
> to Linux development culture, starting with a very friendly separate
> mailing list and IRC channel, and finally moving to work with a kernel
> mentor on a bigger project on the main Linux kernel development lists.
> We have seven women participating this round, and I suspect we'll have
> even more the next round.
> 
> So deal with it.  You're going to have a lot more women in the kernel
> community, and not all of them will be willing to put up with verbal
> abuse.  If you want to attract top talent that also happen to be women
> or racial minorities, the verbal abuse needs to stop.
> 

I have to ask. How much verbal abuse have you received in LKML? And I
don't mean in this thread.

You pointed out a few examples of Linus, and it usually comes from
someone that should know better being told not to do something, and they
continue to do it, and then finally Linus blows up. Linus doesn't start
his cursing at the first email. It takes a few to show that you deserve
a blow up.

Usually sensitive developers would listen the first time they are told.
It's more of the thick skin developers that push the envelope. But I
understand, its the "image" that bothers you.

The scariest thing about Linux kernel development is that because its so
successful, and the development is so open to the world (you are
programming on a stage in a world theater), that thin skin people may
not be comfortable in that environment. What we need are mentors, and
educate people that Linux really isn't that harsh, and that the new
developers actually do have talent, and shouldn't be afraid to post
their code.

The last thing I want to do is to lower the quality of the kernel just
to get a wider range of developers.

-- Steve

Re: [ATTEND] How to act on LKML

[Felipe Contreras]

On Wed, Jul 17, 2013 at 9:40 AM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
> On Wed, Jul 17, 2013 at 09:01:02AM -0500, Felipe Contreras wrote:
>> I know you think "being nice" is better, but do you actually have any
>> evidence for this, or is it just wishful thinking? If you don't have
>> hard evidence, then I'd say you have to admit it's simply your
>> opinion, and I don't think the most successful software project in
>> history should change one if it's core principles simply because *you*
>> think it should.
>
> I haven't shared any "hard evidence" that civility works better in open
> source projects, because to do so would be to bring gender politics into
> the equation.  I don't want to make this into a gendered issue, but
> since you want hard numbers, I will.
>
> Go look at Dreamwidth, the open source Livejournal fork.  It has a good
> code of conduct, so developers are civil to each other.  They encourage
> all patch submissions, and take the time to work with people who don't
> understand their community rules.
>
> The result: 75% of their developers are women.  If you give a flying
> fuck about diversity, and want to attract women to your open source
> project, your developers need to be civil, and not verbally abuse each
> other.

First of all, correlation doesn't imply causation. Second, that's
*one* data-point, it can hardly be considered hard evidence.

Anyway, through the discussion it has been established that swearing
is rare, most of often directed to the code, and on exceptional
occasions directed to people, when they *deserve* it. And you seem to
be implying that women can't tolerate that, so a change needs to be
made in order to attract more women to the project. Is that correct?

Personally I don't believe that. Essentially every other open source
project out there, except the Linux kernel, has some kind code of
conduct, whether it's implicit or explicit, and yet they don't have
many developer women either. But fine, let's suppose what you say it's
true.

As Linus already pointed out, not everybody has to work with
everybody. You don't like Linus' style, you don't *need* to work with
Linus. If, as you say, women don't have such a thick skin, a claim
that I reject (until I can see the hard evidence), and they need a
civil environment, then they can stick with the maintainers that are
softer, and I know there are many of them. Can they not?

Personally I think they can handle criticism like any of the men in
this mailing list do. Unless you royally screw up like Mauro did, you
would be fine.

-- 
Felipe Contreras

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Steven Rostedt]

On Wed, 2013-07-17 at 08:02 -0700, Sarah Sharp wrote:

> Are you volunteering to be a mentor for the FOSS Outreach Program for
> Women? ;)  I will happily take more mentors for the next round in
> November!

If you have someone interested in Real Time OS development. Sure!

-- Steve

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Stefano Stabellini]

On Wed, 17 Jul 2013, Steven Rostedt wrote:
> The last thing I want to do is to lower the quality of the kernel just
> to get a wider range of developers.

Can we stop bringing the quality of the code into the discussion?

I think it's pretty clear that one doesn't need to be verbally abusive
in order to stop bad code from getting into the kernel.

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Felipe Contreras]

On Wed, Jul 17, 2013 at 12:00 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 17 Jul 2013, Steven Rostedt wrote:
>> The last thing I want to do is to lower the quality of the kernel just
>> to get a wider range of developers.
>
> Can we stop bringing the quality of the code into the discussion?

Can you please stop calling open communication abuse? First you have
to explain *why* it was improper in order to call it abuse, and in the
few examples that have been shown, it has been explained that the
behavior was justified (breaking the #1 rule by a lieutenant who
should know better).

> I think it's pretty clear that one doesn't need to be verbally abusive
> in order to stop bad code from getting into the kernel.

You can think whatever you want, others have already shown that
changing the tone of the message in the examples would have changed
the desired effect.

-- 
Felipe Contreras

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Steven Rostedt]

On Wed, 2013-07-17 at 18:00 +0100, Stefano Stabellini wrote:
> On Wed, 17 Jul 2013, Steven Rostedt wrote:
> > The last thing I want to do is to lower the quality of the kernel just
> > to get a wider range of developers.
> 
> Can we stop bringing the quality of the code into the discussion?
> 
> I think it's pretty clear that one doesn't need to be verbally abusive
> in order to stop bad code from getting into the kernel.

Matters what you definition of verbally abusive is. Can I say "your code
is crap!"? I've done that before, and the person I said it to asked me
to explain why it was crap, and I went into detail to why I called it
crap and still think it was crap.

But I'm not even one to insult people, as that's not my personality.
Well, maybe I've called people "idiot" before. But that usually comes
with someone sticking to an idea when all evidence proves otherwise.

Although I'm one of the tame ones on LKML, I still want to reserve my
right to be able to call someone an idiot, if someone is making stupid
ideas and constantly ignores facts that are being presented to them.

Anyway, as I've said several times. Is there a problem here? Besides the
few outbursts from Linus, is there other examples on LKML within the
last year where it is an abusive environment?  From what I see, it is
becoming more mellow, and people have been making efforts to listen to
each other. The trend on LKML is going in the right direction, so I'm a
bit curious to why we need to make such an issue of this. Is it just to
make Linus lower his tone a bit?

-- Steve

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Randy Dunlap]

On 07/16/13 22:32, Sarah Sharp wrote:
> On Tue, Jul 16, 2013 at 10:22:38PM -0700, Darren Hart wrote:
>> On Tue, 2013-07-16 at 21:48 -0700, Linus Torvalds wrote:
>>
>>> Guys, I love my job. The kernel developer community is great. But I
>>> suspect that some of you don't necessarily think about the other side.
>>> I had slashdot discussing my abusive relationship with my wife and
>>> kids thanks to Sarah's comments. Talk about having a thick skin -
>>> trust me when I tell you that I get as well as I give out.
>>
>> That's awful. People suck. I stopped reading slashdot years ago for the
>> quality of the content and commentary, apparently it has not improved.
> 
> Slashdot, Hacker News, and Reddit are all cesspools.  I would much
> rather discuss this topic on LKML or at KS than wade through that muck.
> 
> Bah, let's settle this at KS, away from the court of public opinion.

The only advantage to that is that it is face to face.
The big disadvantage is that it leaves out several hundred (or thousdand)
people.

IOW, I would rather see continued discussion.  Or the patch.  :)


-- 
~Randy

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Willy Tarreau]

On Wed, Jul 17, 2013 at 11:09:31AM -0400, Steven Rostedt wrote:
> What we need are mentors, and educate people that Linux really isn't
> that harsh, and that the new developers actually do have talent, and
> shouldn't be afraid to post their code.

Hey, this is exactly the goal that we seek at the Kernel Recipes
conference in France [1] whose second edition happens in September
this year, and we're still looking for a few speakers. If some
developers want to explain how they were mentored or how they
mentored others, they're welcome! Please contact me off-list.

Willy

[1] https://kernel-recipes.org/

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Stefano Stabellini]

On Wed, 17 Jul 2013, Felipe Contreras wrote:
> On Wed, Jul 17, 2013 at 12:00 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Wed, 17 Jul 2013, Steven Rostedt wrote:
> >> The last thing I want to do is to lower the quality of the kernel just
> >> to get a wider range of developers.
> >
> > Can we stop bringing the quality of the code into the discussion?
> 
> Can you please stop calling open communication abuse?

Open communication is one thing, abuse is another, so I agree with you
there.


> First you have
> to explain *why* it was improper in order to call it abuse, and in the
> few examples that have been shown, it has been explained that the
> behavior was justified (breaking the #1 rule by a lieutenant who
> should know better).

Abuse is never justified, I hope that's clear for everybody.
Two wrongs don't make a right.

So we are down to the definition of verbal abuse.
The Oxford dictionary gives me:

"speak to (someone) in an insulting and offensive way"

For example I think that calling somebody a moron qualifies.



> > I think it's pretty clear that one doesn't need to be verbally abusive
> > in order to stop bad code from getting into the kernel.
> 
> You can think whatever you want, others have already shown that
> changing the tone of the message in the examples would have changed
> the desired effect.
 
I disagree and it is certainly not the case in my experience.

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Al Viro]

On Wed, Jul 17, 2013 at 06:00:46PM +0100, Stefano Stabellini wrote:
> On Wed, 17 Jul 2013, Steven Rostedt wrote:
> > The last thing I want to do is to lower the quality of the kernel just
> > to get a wider range of developers.
> 
> Can we stop bringing the quality of the code into the discussion?

No.

> I think it's pretty clear that one doesn't need to be verbally abusive
> in order to stop bad code from getting into the kernel.

At the risk of sounding pedantic...  The above is true *and* irrelevant
as stated, and any attempts to read it in less irrelevant way result
in statements that are absolutely non-obvious and very likely false.
	* some amount of bad code will be getting into the kernel, in
any scenario short of complete cessation of development
	* there certainly are ways to prevent any given bad code from
getting into the kernel, once you have identified it.  Even leaving
aside completely ridiculous ones ("after WW3 nobody will push that into
the tree", etc.), one can always watch all trees for specific code and
refuse to pull if it has slipped in.
	* "once you have identified it" part of the above is essential
and does not scale.
In other words, it's not "can we stop it from happening", it's "how
much will be slippling in with given setup".  And _this_ is where your
position becomes completely unfounded.  It's not at all clear that
vague alternatives being proposed will *not* result in more crap getting
in.

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Steven Rostedt]

On Wed, 2013-07-17 at 10:41 -0700, Randy Dunlap wrote:

> The big disadvantage is that it leaves out several hundred (or thousdand)
> people.

I see that as an advantage ;-)

We could video tape it for the entertainment value.

-- Steve

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Felipe Contreras]

On Wed, Jul 17, 2013 at 12:56 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 17 Jul 2013, Felipe Contreras wrote:
>> On Wed, Jul 17, 2013 at 12:00 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Wed, 17 Jul 2013, Steven Rostedt wrote:
>> >> The last thing I want to do is to lower the quality of the kernel just
>> >> to get a wider range of developers.
>> >
>> > Can we stop bringing the quality of the code into the discussion?
>>
>> Can you please stop calling open communication abuse?
>
> Open communication is one thing, abuse is another, so I agree with you
> there.

You call it abuse, others don't.

>> First you have
>> to explain *why* it was improper in order to call it abuse, and in the
>> few examples that have been shown, it has been explained that the
>> behavior was justified (breaking the #1 rule by a lieutenant who
>> should know better).
>
> Abuse is never justified, I hope that's clear for everybody.
> Two wrongs don't make a right.
>
> So we are down to the definition of verbal abuse.
> The Oxford dictionary gives me:
>
> "speak to (someone) in an insulting and offensive way"

Here's another definition from Merriam Webster:

* language that condemns or vilifies usually unjustly, intemperately,
and angrily

That definition fits my idea of abuse. Linus was not unjust, so it's not abuse.

> For example I think that calling somebody a moron qualifies.

I don't, specially if the person is indeed being a moron.

>> > I think it's pretty clear that one doesn't need to be verbally abusive
>> > in order to stop bad code from getting into the kernel.
>>
>> You can think whatever you want, others have already shown that
>> changing the tone of the message in the examples would have changed
>> the desired effect.
>
> I disagree and it is certainly not the case in my experience.

Suit yourself.

If want you wanted was to voice your opinion, I think you have already
done that.

-- 
Felipe Contreras

open conflicts vs. hidden conflicts (was: [ 00/19] 3.10.1-stable review)

[Ingo Molnar]

* Sarah Sharp <sarah.a.sharp@linux.intel.com> wrote:

> On Mon, Jul 15, 2013 at 12:07:56PM -0700, Linus Torvalds wrote:
> > On Mon, Jul 15, 2013 at 11:46 AM, Sarah Sharp
> > <sarah.a.sharp@linux.intel.com> wrote:
> > >
> > > Bullshit.  I've seen you be polite, and explain to clueless 
> > > maintainers why there's no way you can revert their merge that 
> > > caused regressions, and ask them to fit it without resorting to 
> > > tearing them down emotionally:
> > 
> > Oh, I'll be polite when it's called for.
> > 
> > But when people who know better send me crap, I'll curse at them.
> > 
> > I suspect you'll notice me cursing *way* more at top developers than 
> > random people on the list. I expect more from them, and conversely 
> > I'll be a lot more upset when they do something that I really think 
> > was not great.
> > 
> > For example, my latest cursing explosion was for the x86 maintainers, 
> > and it comes from the fact that I *know* they know to do better. The 
> > x86 tip pulls have generally been through way more testing than most 
> > other pulls I get (not just compiling, but even booting randconfigs 
> > etc). So when an x86 pull request comes in that clearly missed that 
> > expected level of quality, I go to town.
> 
> Good lord.  So anyone that is one of your "top maintainers" could be 
> exposed to your verbal abuse just because they "should have known 
> better"?

As one of those maintainers who sends lots of patches/commits/trees to 
Linus and has done so for the last 15+ years, and as one who has messed up 
enough times to have been grilled by Linus probably more times than anyone 
else in this thread, I guess I should chime in with my first hand 
experience.

In short: you are wrong on many levels.

1)

Your notion that conflicts and insults somehow hurt group cooperation is 
wrong. It is a scientific fact that open conflict _helps_ cooperation 
while hidden conflict hurts it.

There's a famous psychological study that examined the cooperation 
patterns within string quartets playing music (Murnighan & Conlon, 1991): 
it evaluated different string quartets, examining their internal 
'politics' and their conflict resolution techniques.

Effective, successful string quartets embraced open conflict: they 
honestly told each other when they messed up, not avoiding confrontation. 
Open conflict allowed them to eventually play music as a team, 
incorporating the concerns of all the musicians.

'Polite' string quartets on the other hand generally played poorer music, 
because each musician played individually, not as a team. The conflicts 
were never really resolved.

With a quick search I have not found the original study on the open web, 
but here's a citation of it:

  " Murnighan 84 Conlon (1991) found that effective string quartets
    accepted conflict as positive, and incorporated one another's
    concerns into the final product, whereas less successful quartets
    typically avoided conflict."

    http://www.delta.gatech.edu/papers/maximizing.pdf

[ I think this study might explain in part why the high tech industry is 
  so strong in northern Europe: honesty pays off. ]

2)

Your notion that insults are harmful because they 'hurt' is misleading to 
such a level that it's almost wrong.

Insults do hurt of course, but that argument misses the full context: in 
real life the typical substitute for an avoided open conflict is not 
singing kumbaya around the camp fire, but _hidden_ conflict.

Hidden, suppressed conflicts, office politics and passive-aggressive 
behavior are _far_ more harmful than the occasional four letter word:

There was a recent study that showed that 'giving the cold shoulder', 'the 
silent treatment' and other forms of passive-aggressive violence activate 
exactly the same brain regions as being physically injured. (!)

The difference between Linus's chiding of maintainers who messed up and 
'hidden' conflicts is significant:

  1) passive-aggressive violence can go on essentially forever, without
     outsiders noticing it. You won't notice it even on lkml, and yes, it 
     occurs all the time ...

  2) passive-aggressive violence _thrives_ in 'polite', 'professional'
     environments that supress open conflict. Hidden violence also occurs 
     in a lot of 'polite' open source projects that I know.

  3) so the net duration of the conflict is _far_ shorter in the Linus
     case.

I will pick an honest, colorful Linus flame over workplace mobbing or 
other forms of substitute passive-aggressive violence any time of the day.

3)

I couldn't cite a single example where Linus flamed me unprovoked, 
unjustified, just for the sake of letting off steam or any other petty 
reason. I've not seen Linus flame newbies and I've not seen him 
micro-manage people over unimportant details.

In the large majority of colorful flames the flame was over something that 
_matters to the kernel_ - and heck do I prefer a top level maintainer who 
cares and who is honest, over someone who is indifferent or sloppy ...

Thanks,

	Ingo

RE: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Luck, Tony]

> Those are just stories; things that happened. What you need to provide
> is *evidence* that if the community changes, things will be better,
> and unless you have a study of series of collaborative groups like the
> Linux kernel, that demonstrates that suppressing swearing has a
> positive effect in the community, I'd say all you have is an
> *opinion*.

1) There isn't going to be any hard evidence - this isn't a physics problem,
or even an engineering problem. It's a social problem.  There are no other
collaborative groups sufficiently similar to the Linux kernel community, so there
are no studies that would be relevant. Asking for the impossible is just a
lame delaying tactic.

2) Sarah hasn't even asked to cut down on the swearing - so why mention
it at all? Did you even read the thread?

So I shall (for comedic effect) indulge in my own (uncharacteristic) bit
of name calling and dub thee a troll (and every other bad thing that anyone
is ever alleged of calling another on LKML, just to be sure).

-Tony

RE: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Luck, Tony]

> Those are just stories; things that happened. What you need to provide
> is *evidence* that if the community changes, things will be better,
> and unless you have a study of series of collaborative groups like the
> Linux kernel, that demonstrates that suppressing swearing has a
> positive effect in the community, I'd say all you have is an
> *opinion*.

1) There isn't going to be any hard evidence - this isn't a physics problem,
or even an engineering problem. It's a social problem.  There are no other
collaborative groups sufficiently similar to the Linux kernel community, so there
are no studies that would be relevant. Asking for the impossible is just a
lame delaying tactic.

2) Sarah hasn't even asked to cut down on the swearing - so why mention
it at all? Did you even read the thread?

So I shall (for comedic effect) indulge in my own (uncharacteristic) bit
of name calling and dub thee a troll (and every other bad thing that anyone
is ever alleged of calling another on LKML, just to be sure).

-Tony

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Al Viro]

On Wed, Jul 17, 2013 at 06:56:16PM +0100, Stefano Stabellini wrote:

> Abuse is never justified, I hope that's clear for everybody.

Depends on details of your definition of abuse.

> So we are down to the definition of verbal abuse.
> The Oxford dictionary gives me:
> 
> "speak to (someone) in an insulting and offensive way"

Insufficient details to tell if the statement above is correct.
Insulting and offensive to *whom*?

I have seen people making completely revolting statements about
e.g. females in general and get extremely insulted when said
statements had been described as sexist, no matter how neutral
had description been.  I have seen people deeply insulted by
being told (in absolutely neutral expressions) that recipe they
had offered for some task will not do what they said it would,
when the simple experiment (reproduced by a lot of people
present) would have clearly demonstrated just that.  The same
people tend to get _really_ insulted when somebody reports
the result of said experiment.  And anybody who'd been on
the net for a year (hell, a month would suffice) can bring
a lot more interesting cases...

BTW, is it an abuse to describe somebody as a demagogue?

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Felipe Contreras]

On Wed, Jul 17, 2013 at 1:24 PM, Luck, Tony <tony.luck@intel.com> wrote:
>> Those are just stories; things that happened. What you need to provide
>> is *evidence* that if the community changes, things will be better,
>> and unless you have a study of series of collaborative groups like the
>> Linux kernel, that demonstrates that suppressing swearing has a
>> positive effect in the community, I'd say all you have is an
>> *opinion*.
>
> 1) There isn't going to be any hard evidence - this isn't a physics problem,
> or even an engineering problem. It's a social problem.  There are no other
> collaborative groups sufficiently similar to the Linux kernel community, so there
> are no studies that would be relevant. Asking for the impossible is just a
> lame delaying tactic.

There is evidence for social problems and their solutions, but anyway,
so in fact Sarah doesn't *know* if changing that behavior would be
beneficial or detrimental to the project.

> 2) Sarah hasn't even asked to cut down on the swearing - so why mention
> it at all? Did you even read the thread?

She didn't ask, she essentially demanded[1]:

> I want everyone (including Linus) to be harsh with code but gentle with people.

Let's call things by their name; Sarah doesn't know if what she wants
will help the project, she merely thinks so. It is merely an
**opinion**, it is not backed by evidence, and it might be shared by
some Linux developers, but it's still just an opinion.

Linus already said he is not going to change, so that's that. Now the
only thing that remains open is the discussion about better ways to
work together, which probably will happen in the kernel summit, but I
think it's pretty clear that an official code of conduct that forbids
insulting either people or code is out of the question.

Cheers.

[1] http://article.gmane.org/gmane.linux.kernel.stable/58443

-- 
Felipe Contreras

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Felipe Contreras]

On Wed, Jul 17, 2013 at 1:24 PM, Luck, Tony <tony.luck@intel.com> wrote:
>> Those are just stories; things that happened. What you need to provide
>> is *evidence* that if the community changes, things will be better,
>> and unless you have a study of series of collaborative groups like the
>> Linux kernel, that demonstrates that suppressing swearing has a
>> positive effect in the community, I'd say all you have is an
>> *opinion*.
>
> 1) There isn't going to be any hard evidence - this isn't a physics problem,
> or even an engineering problem. It's a social problem.  There are no other
> collaborative groups sufficiently similar to the Linux kernel community, so there
> are no studies that would be relevant. Asking for the impossible is just a
> lame delaying tactic.

There is evidence for social problems and their solutions, but anyway,
so in fact Sarah doesn't *know* if changing that behavior would be
beneficial or detrimental to the project.

> 2) Sarah hasn't even asked to cut down on the swearing - so why mention
> it at all? Did you even read the thread?

She didn't ask, she essentially demanded[1]:

> I want everyone (including Linus) to be harsh with code but gentle with people.

Let's call things by their name; Sarah doesn't know if what she wants
will help the project, she merely thinks so. It is merely an
**opinion**, it is not backed by evidence, and it might be shared by
some Linux developers, but it's still just an opinion.

Linus already said he is not going to change, so that's that. Now the
only thing that remains open is the discussion about better ways to
work together, which probably will happen in the kernel summit, but I
think it's pretty clear that an official code of conduct that forbids
insulting either people or code is out of the question.

Cheers.

[1] http://article.gmane.org/gmane.linux.kernel.stable/58443

-- 
Felipe Contreras

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Sarah Sharp]

On Wed, Jul 17, 2013 at 11:09:31AM -0400, Steven Rostedt wrote:
> On Wed, 2013-07-17 at 07:48 -0700, Sarah Sharp wrote:
> 
> > > Does that sound like there are not going to have enough direct/thick skin
> > > new kernel developers around to maintain the future Linux community? Maybe
> > > just need a better pipeline for people comfortable for this culture?
> > 
> > No, we don't need a better pipeline for people who can "put up with
> > shit".  We need a better pipeline for people who can work together
> > civilly, and still get shit done.
> > 
> > I'm working on getting a pipeline of women into kernel development,
> > through the FOSS Outreach Program for Women.  They slowly get introduced
> > to Linux development culture, starting with a very friendly separate
> > mailing list and IRC channel, and finally moving to work with a kernel
> > mentor on a bigger project on the main Linux kernel development lists.
> > We have seven women participating this round, and I suspect we'll have
> > even more the next round.
> > 
> > So deal with it.  You're going to have a lot more women in the kernel
> > community, and not all of them will be willing to put up with verbal
> > abuse.  If you want to attract top talent that also happen to be women
> > or racial minorities, the verbal abuse needs to stop.
> > 
> 
> I have to ask. How much verbal abuse have you received in LKML? And I
> don't mean in this thread.

I assume you also want me to exclude the verbal abuse and personal
threats I've received via email and my blog because of this thread.
But, just for reference, I'll post them here as well.

Here's a gem from a senior software developer at Nvidia:
https://picasaweb.google.com/116960357493251979546/Trolls#5901298464591248626

And another email from a software developer in Portland, where I live:
https://picasaweb.google.com/116960357493251979546/Trolls#5901288095984358098

On my blog, here's some choice comments, mostly asking me to quit kernel
development, along with more than a few misogynist comments:

"You volunteered to help out on the Linux journey. He never volunteered
to care for your feelings, nor did anyone else. It’s an opt-in community
and you can always opt out at any time. Caveat emptor."

"You’re no one compared to Linus. Start being Alan Cox or Theodore T’so
first to criticize him for his behaviour."

"Drama Queen"

"The LKML is not a place for easily offended girls to be. Get over
yourself."

"shit, just what we need – a bitch running around crying about how hurt
her feelings are."

"Oy vey you poor goyi…girl. You need to teach these sexist boys that
being racist is wrong. Think of the wonderful things that womyn have
done in the IT field. Clearly Linus is a rape apologist who fosters
negative views of minorities."

"This is why women are viewed as pathetic jokes, especially in the tech
world – because you’re weak and ineffectual, insufferable pansies who
expect the world to cater and accommodate your thin skin and easily
offended hyper-sensibilities. Grow the fuck up bitch. It’s real cute how
you’ve tried to paint yourself as some gallant Joan of Arc, crusading
against “muh bigotry” and “muh intolerance.” You’re a feminist joke, one
in a very long line."


Speaking out about this has made the crazies come out of the woodwork.
It means I now have to book a rental car so I don't have to be on public
transit, and book a hotel room so I don't have to be home.  Those
crazies, especially the local Portland SW developer, can easily find my
home address from my blog domain name whois info.

Being a woman in open source, and speaking out, means I put my personal
safety in jeopardy.  I should not have to put up with this.  We should
be able to have a private conversation at KS without the court of public
opinion getting involved.  However, that's not the way it went, and now
I have to deal with the verbal abuse, sexist statements, and threats
that are the backlash from this thread.

> You pointed out a few examples of Linus, and it usually comes from
> someone that should know better being told not to do something, and they
> continue to do it, and then finally Linus blows up. Linus doesn't start
> his cursing at the first email. It takes a few to show that you deserve
> a blow up.
> 
> Usually sensitive developers would listen the first time they are told.
> It's more of the thick skin developers that push the envelope. But I
> understand, its the "image" that bothers you.

No, it's actually some of the comments I've received that bother me.
For example, I would never want to deal with the misogynist troll,
Lubin, EVER again.

http://permalink.gmane.org/gmane.linux.usb.general/42482

"You may be seen as a liability by Intel preaching "feminism" on a
public forum.  From their point of view: will you play the gender card
on them.  Here is what you did: Instead of realizing that I was being
_very_ sympathetic to a more diverse Linux development environment by
using the phrase "the old boys club", you pretended to take offense, not
realizing you're in fact becoming a liability.  That's okay. Honest
mistake."

Telling me my job at Intel is in jeopardy because I'm complaining about
sexist statements is a threat.  It's verbal abuse, and I won't take it.
I shouldn't have to put up with these kinds of statements and personal
attacks.

> The scariest thing about Linux kernel development is that because its so
> successful, and the development is so open to the world (you are
> programming on a stage in a world theater), that thin skin people may
> not be comfortable in that environment. What we need are mentors, and
> educate people that Linux really isn't that harsh, and that the new
> developers actually do have talent, and shouldn't be afraid to post
> their code.

We do need mentors.  Thank you for signing up to be one.

I disagree that we should educate people that Linux really isn't that
harsh.  We are technically harsh, and always will be.  Linux kernel
developers require perfect code, and perfectly formatted patches.
Setting up mentees to think otherwise is simply not advisable.  However,
we can assure them that they won't see harsh _personal_ attacks, and
coach them through dealing with their first harsh attacks against their
_code_.

> The last thing I want to do is to lower the quality of the kernel just
> to get a wider range of developers.

I agree.  We shouldn't lower our coding standards.  We should however,
take a very close look at our personal communication styles, in order to
ensure we aren't excluding a wide range of developers.

Sarah Sharp

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Sarah Sharp]

On Wed, Jul 17, 2013 at 01:28:59PM -0400, Steven Rostedt wrote:
> On Wed, 2013-07-17 at 18:00 +0100, Stefano Stabellini wrote:
> > On Wed, 17 Jul 2013, Steven Rostedt wrote:
> > > The last thing I want to do is to lower the quality of the kernel just
> > > to get a wider range of developers.
> > 
> > Can we stop bringing the quality of the code into the discussion?
> > 
> > I think it's pretty clear that one doesn't need to be verbally abusive
> > in order to stop bad code from getting into the kernel.
> 
> Matters what you definition of verbally abusive is. Can I say "your code
> is crap!"? I've done that before, and the person I said it to asked me
> to explain why it was crap, and I went into detail to why I called it
> crap and still think it was crap.
> 
> But I'm not even one to insult people, as that's not my personality.
> Well, maybe I've called people "idiot" before. But that usually comes
> with someone sticking to an idea when all evidence proves otherwise.

I've said it before, but I'll say it again.  I'm fine with calling
_code_ crap (or other forms of poop).  I'm fine with someone saying,
"Fix this fuck up, RIGHT NOW!"  I'm not fine with someone personally
attacking a developer and telling them to "SHUT THE FUCK UP!"

> Although I'm one of the tame ones on LKML, I still want to reserve my
> right to be able to call someone an idiot, if someone is making stupid
> ideas and constantly ignores facts that are being presented to them.

If they ignore facts from two emails, fine, call them an idiot and drive
them off with flames of fire and verbal abuse.  But we all need to take
the time to explain the facts, politely, without cussing or personal
attacks, in the first email to the developer.

> Anyway, as I've said several times. Is there a problem here? Besides the
> few outbursts from Linus, is there other examples on LKML within the
> last year where it is an abusive environment?

You really want me to dig up more shit from other developers?  I think
that's an exercise probably best left to a private discussion at KS.

> From what I see, it is
> becoming more mellow, and people have been making efforts to listen to
> each other. The trend on LKML is going in the right direction, so I'm a
> bit curious to why we need to make such an issue of this. Is it just to
> make Linus lower his tone a bit?

Again, I'll re-emphasize this.  I'm not "demanding" that Linus or anyone
in this community change their personal style of communication.  I'm
simply providing incentive for them to change, and asking that they
consider changing.  I'm asking to have an open discussion about this at
KS, away from the public court of opinion.  I cannot "manage" personal
change.  I cannot "force" people to have the will to change.  I can only
ask politely, and advocate for change.  Please don't equate advocating
for change with demanding change.

Sarah Sharp

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[David Lang]

On Wed, 17 Jul 2013, Sarah Sharp wrote:

> On Wed, Jul 17, 2013 at 11:09:31AM -0400, Steven Rostedt wrote:
>> On Wed, 2013-07-17 at 07:48 -0700, Sarah Sharp wrote:
>>
>>>> Does that sound like there are not going to have enough direct/thick skin
>>>> new kernel developers around to maintain the future Linux community? Maybe
>>>> just need a better pipeline for people comfortable for this culture?
>>>
>>> No, we don't need a better pipeline for people who can "put up with
>>> shit".  We need a better pipeline for people who can work together
>>> civilly, and still get shit done.
>>>
>>> I'm working on getting a pipeline of women into kernel development,
>>> through the FOSS Outreach Program for Women.  They slowly get introduced
>>> to Linux development culture, starting with a very friendly separate
>>> mailing list and IRC channel, and finally moving to work with a kernel
>>> mentor on a bigger project on the main Linux kernel development lists.
>>> We have seven women participating this round, and I suspect we'll have
>>> even more the next round.
>>>
>>> So deal with it.  You're going to have a lot more women in the kernel
>>> community, and not all of them will be willing to put up with verbal
>>> abuse.  If you want to attract top talent that also happen to be women
>>> or racial minorities, the verbal abuse needs to stop.
>>>
>>
>> I have to ask. How much verbal abuse have you received in LKML? And I
>> don't mean in this thread.
>
> I assume you also want me to exclude the verbal abuse and personal
> threats I've received via email and my blog because of this thread.
> But, just for reference, I'll post them here as well.

Not that I am in any way defending these posts, but does the behavior of 
outsiders like this in other forums really reflect the LKML attitude? Or does it 
reflect the fact that there are a lot of people out there who you really do not 
want to deal with (no matter what the topic)

Just about any topic that you take a firm stand on (anything other than pure 
status-quo), and your stand gets out to as many people as have heard about this 
thread, is going to generate a LOT of offensive and irrational hate messages. 
Linus talked about the ongoing abuse he receives earlier in the thread, so it's 
not just people attacking you.

David Lang

Re: [ATTEND] How to act on LKML

[David Miller]

From: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date: Wed, 17 Jul 2013 07:40:43 -0700

> If you give a flying fuck about diversity
...

Pot, meet kettle.

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Steven Rostedt]

On Wed, 2013-07-17 at 11:51 -0700, Sarah Sharp wrote:

> > I have to ask. How much verbal abuse have you received in LKML? And I
> > don't mean in this thread.
> 
> I assume you also want me to exclude the verbal abuse and personal
> threats I've received via email and my blog because of this thread.
> But, just for reference, I'll post them here as well.

That's the nastiness of the Internet, a different topic than LKML
development. And I don't consider this thread really a LKML thread, as
it's about social behavior and nothing about the Linux kernel itself.

> 
> Here's a gem from a senior software developer at Nvidia:
> https://picasaweb.google.com/116960357493251979546/Trolls#5901298464591248626
> 
> And another email from a software developer in Portland, where I live:
> https://picasaweb.google.com/116960357493251979546/Trolls#5901288095984358098

Both are cowardly trolls that didn't post publicly.

> 
> On my blog, here's some choice comments, mostly asking me to quit kernel
> development, along with more than a few misogynist comments:
> 
> "You volunteered to help out on the Linux journey. He never volunteered
> to care for your feelings, nor did anyone else. It’s an opt-in community
> and you can always opt out at any time. Caveat emptor."
> 
> "You’re no one compared to Linus. Start being Alan Cox or Theodore T’so
> first to criticize him for his behaviour."
> 
> "Drama Queen"
> 
> "The LKML is not a place for easily offended girls to be. Get over
> yourself."
> 
> "shit, just what we need – a bitch running around crying about how hurt
> her feelings are."
> 
> "Oy vey you poor goyi…girl. You need to teach these sexist boys that
> being racist is wrong. Think of the wonderful things that womyn have
> done in the IT field. Clearly Linus is a rape apologist who fosters
> negative views of minorities."
> 
> "This is why women are viewed as pathetic jokes, especially in the tech
> world – because you’re weak and ineffectual, insufferable pansies who
> expect the world to cater and accommodate your thin skin and easily
> offended hyper-sensibilities. Grow the fuck up bitch. It’s real cute how
> you’ve tried to paint yourself as some gallant Joan of Arc, crusading
> against “muh bigotry” and “muh intolerance.” You’re a feminist joke, one
> in a very long line."

Again, this is the Internet social media, which is not an environment
for productivity, but a cesspool of filth. Off topic to what I asked.

> 
> 
> Speaking out about this has made the crazies come out of the woodwork.

And what did you expect? The Internet if filled with assholes.

> It means I now have to book a rental car so I don't have to be on public
> transit, and book a hotel room so I don't have to be home.  Those
> crazies, especially the local Portland SW developer, can easily find my
> home address from my blog domain name whois info.
> 
> Being a woman in open source, and speaking out, means I put my personal
> safety in jeopardy.  I should not have to put up with this.  We should
> be able to have a private conversation at KS without the court of public
> opinion getting involved.  However, that's not the way it went, and now
> I have to deal with the verbal abuse, sexist statements, and threats
> that are the backlash from this thread.

This is a real issue, but not one that LKML can solve, nor Linus being
nicer will have any affect on it. It is the social media and the trolls
that live within it. Women, in particular, that fight for social change,
bring out the worse of the Internet dung bugs and they cowardly will
attack you behind anonymous accounts or private email.

You came out swinging at Linus when he mentioned to Greg that he needs
to yell at people more. You did that on a public list. I was actually
very impressed by your bravery in doing so because I knew (and expected
that you knew too) that this will stir up the feces that exists under
the Internet shoe.
 
The Internet is a dangerous tool. Like I really think Linus quietly
regrets saying "SHUT THE FUCK UP", it was done publicly and you and
others have been using it against him. By attacking Linus publicly, will
bring out the low life that will attack you. Is that right? No, but it's
a reality that you know far too well.

But you didn't yell at Linus because you get trolls on your blog and
private emails. You yelled at him because you were upset at the way he
yells at others thinking that this will keep good people from joining
our community. This may be the case, but I asked you, do you get yelled
at by kernel developers for your work? And again, not about this thread,
because this thread is not technical and has nothing directly to do with
Linux.


> 
> > You pointed out a few examples of Linus, and it usually comes from
> > someone that should know better being told not to do something, and they
> > continue to do it, and then finally Linus blows up. Linus doesn't start
> > his cursing at the first email. It takes a few to show that you deserve
> > a blow up.
> > 
> > Usually sensitive developers would listen the first time they are told.
> > It's more of the thick skin developers that push the envelope. But I
> > understand, its the "image" that bothers you.
> 
> No, it's actually some of the comments I've received that bother me.
> For example, I would never want to deal with the misogynist troll,
> Lubin, EVER again.
> 
> http://permalink.gmane.org/gmane.linux.usb.general/42482
> 
> "You may be seen as a liability by Intel preaching "feminism" on a
> public forum.  From their point of view: will you play the gender card
> on them.  Here is what you did: Instead of realizing that I was being
> _very_ sympathetic to a more diverse Linux development environment by
> using the phrase "the old boys club", you pretended to take offense, not
> realizing you're in fact becoming a liability.  That's okay. Honest
> mistake."
> 
> Telling me my job at Intel is in jeopardy because I'm complaining about
> sexist statements is a threat.  It's verbal abuse, and I won't take it.
> I shouldn't have to put up with these kinds of statements and personal
> attacks.

He gave you his personal opinion. He gave you his opinion that your job
may be in jeopardy. Is he your manager? Does he work or represent Intel?
If not, ignore him. I don't see that as verbal abuse. Tell him "who are
you to decide my job?".

> 
> > The scariest thing about Linux kernel development is that because its so
> > successful, and the development is so open to the world (you are
> > programming on a stage in a world theater), that thin skin people may
> > not be comfortable in that environment. What we need are mentors, and
> > educate people that Linux really isn't that harsh, and that the new
> > developers actually do have talent, and shouldn't be afraid to post
> > their code.
> 
> We do need mentors.  Thank you for signing up to be one.
> 
> I disagree that we should educate people that Linux really isn't that
> harsh.  We are technically harsh, and always will be.  Linux kernel
> developers require perfect code, and perfectly formatted patches.

I agree.

> Setting up mentees to think otherwise is simply not advisable.  However,
> we can assure them that they won't see harsh _personal_ attacks, and
> coach them through dealing with their first harsh attacks against their
> _code_.

That's what I meant. Sorry it was misunderstood. Yeah, it may be harsh
in the fact that we expect high quality code to get into the kernel, but
I meant, the harshness isn't personal unless you try to make it that
way.

> 
> > The last thing I want to do is to lower the quality of the kernel just
> > to get a wider range of developers.
> 
> I agree.  We shouldn't lower our coding standards.  We should however,
> take a very close look at our personal communication styles, in order to
> ensure we aren't excluding a wide range of developers.

I've said it several times in this thread. I think the tone of LKML has
been getting more tame, and it's not your father's mailing list
anymore. ;-)

-- Steve

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Willy Tarreau]

On Wed, Jul 17, 2013 at 11:51:38AM -0700, Sarah Sharp wrote:
> I assume you also want me to exclude the verbal abuse and personal
> threats I've received via email and my blog because of this thread.
> But, just for reference, I'll post them here as well.

[ comments removed not to give them too much publicity ]

(...)

Sadly now you see that your friends are here on LKML and that some
outsiders are much much worse. You'd probably prefer being criticized
by Linus for your design choices than having to ever work with one of
the stupid donkeys that wrote the excerpts you published.

(...)
> Speaking out about this has made the crazies come out of the woodwork.

It always happens on public discussions unfortunately. It's the only
way they find to feel like they exist. (BTW calling them crazies is
an attack to their person and may be contrary to what you'd like to
see on this ML, no ?).

> It means I now have to book a rental car so I don't have to be on public
> transit, and book a hotel room so I don't have to be home.  Those
> crazies, especially the local Portland SW developer, can easily find my
> home address from my blog domain name whois info.

There is no reason to fear the stupid who use public places to threaten.
It's their moment of glory. After that they go to the toilets and have a
5-to-1 session and they relax.

> Being a woman in open source, and speaking out, means I put my personal
> safety in jeopardy.  I should not have to put up with this.  We should
> be able to have a private conversation at KS without the court of public
> opinion getting involved.  However, that's not the way it went, and now
> I have to deal with the verbal abuse, sexist statements, and threats
> that are the backlash from this thread.

That's the risk of launching very sensitive subjects on mailing lists. I
don't know if you remembers the era of the trolls, we had almost once a
month 7-8 years ago, it was hard to get rid of them. They just started
non-tech subjects that always derived into flame wars. Here you started
a subject of real concern that merits being discussed about, but which
relates more to emotion and culture, and derives the same way.

> > Usually sensitive developers would listen the first time they are told.
> > It's more of the thick skin developers that push the envelope. But I
> > understand, its the "image" that bothers you.
> 
> No, it's actually some of the comments I've received that bother me.
> For example, I would never want to deal with the misogynist troll,
> Lubin, EVER again.
(...)

> Telling me my job at Intel is in jeopardy because I'm complaining about
> sexist statements is a threat.

I was about to comment on the fact that you're 3 from intel who'd better
use your private addresses to avoid the image of "intel vs Linus" that
some may get but since all your comments have been clean and argumented,
there is no reason for anyone sane to consider them inappropriate. Intel
would be foolish to fire you when you tried to raise the professional
look of the Linux community even if many (including me) disagree.

> It's verbal abuse, and I won't take it.
> I shouldn't have to put up with these kinds of statements and personal
> attacks.

Too late, it's done, you must have no regrets and stay firmly in your shoes
(and listen to sane people's arguments).

> I disagree that we should educate people that Linux really isn't that
> harsh.  We are technically harsh, and always will be.  Linux kernel
> developers require perfect code, and perfectly formatted patches.
> Setting up mentees to think otherwise is simply not advisable.

I disagree. Precisely what the newcomers need is to find their way through
the forest of maintainers, reviewers, etc... You can send patches in whatever
format, someone will always tell you how to fix this. You'll at least get one
nice person taking the time to explain to you. We all experienced this. What
needs to be taught to newcomers is how the process works, to ignore the few
irrespectful people who will immediately comment on their indentation with
harsh words and better wait for the more teaching comments that come later,
to take care of every such comments, ask when they don't understand, and
repost.

The questions I've got from newcomers were along "Have you ever got an
e-mail from Linus ? Wow... Have you ever met him ? No ? Strange, are there
many people who don't meet ?" etc... They're completely lost because for
them this project is almost sci-fi. I try to make them understand that my
contribution is very small and non-important and that I'm as dumb as they
are so there is no reason they can't participate. Once they can accept
that, most of the job is done. The remaining part is to ensure they're
not discouraged by the formalities about merge windows, subsystems, -rc,
etc.

> However,
> we can assure them that they won't see harsh _personal_ attacks, and
> coach them through dealing with their first harsh attacks against their
> _code_.

No I prefer to tell them that with I don't know how many thousands of
subscribers, they *will* get some personal attacks that they can simply
ignore just like when they cross a drunk man on the street shouting words
at bystanders.

Best regards,
Willy

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Geert Uytterhoeven]

On Wed, Jul 17, 2013 at 9:29 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> I've said it several times in this thread. I think the tone of LKML has
> been getting more tame, and it's not your father's mailing list
> anymore. ;-)

Indeed.

Several (definitely more than 5) years ago, there was a presentation (IIRC
even a keynote) at OLS about the hostility of lkml to newcomers.
Bad and good examples were shown. Several attendees couldn't believe
who wrote one of the good examples, as its author was used to be known
for his very harsh emails several years before ;-)

And in the mean time, things have improved even more!

Side note: lots of this use of words is cultural. When I first visited the USA,
I was surprised to never hear anyone use four letter words, unlike in movies
exported from the USA. While these English words had become common in
Europe (at least in Belgium)...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Paul E. McKenney]

On Wed, Jul 17, 2013 at 10:14:49AM +0400, James Bottomley wrote:
> On Tue, 2013-07-16 at 14:18 -0700, Paul E. McKenney wrote:
> > On Tue, Jul 16, 2013 at 10:27:09PM +0400, James Bottomley wrote:
> > > On Mon, 2013-07-15 at 15:38 -0700, Linus Torvalds wrote:
> > > > On Mon, Jul 15, 2013 at 3:08 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > > > >
> > > > > Can we please make this into a Kernel Summit discussion. I highly doubt
> > > > > we would solve anything, but it certainly would be a fun segment to
> > > > > watch :-)
> > > > 
> > > > I think we should, because I think it's the kind of thing we really
> > > > need at the KS - talking about "process".
> > > 
> > > Can you formulate the process issue to discuss?  I've heard "Linus needs
> > > to yell less at people" and "the mailing lists need to be more
> > > 'professional'" neither of which seems to identify an actual process.
> > > Are we perhaps discussing guidelines for giving feedback on patches?
> > > 
> > > > At the same time, I really don't know what the format would possibly
> > > > be like for it to really work as a reasonable discussion. And I think
> > > > that is important, because this kind of subject is *not* likely
> > > > possible in the traditional "people sit around tables and maybe
> > > > somebody has a few slides" format.
> > > 
> > > > A small panel discussion with a few people (fiveish?) that have very
> > > > different viewpoints, along with baskets of rotten fruit set out on
> > > > the tables? That could be fun. And I'm serious, although we might want
> > > > to limit the size of the fruit to smaller berries ;)
> > > 
> > > How about Lychees?  They're prickly on the outside, very wet on the
> > > inside and have large stones ...
> > 
> > They taste good, too.
> > 
> > > But what are the viewpoints?  "maintainers need to yell more"?
> > > "maintainers need to yell less"?  I don't think I agree with either.
> > > I'm perfectly happy to run linux-scsi along reasonable standards of
> > > civility and try to keep the debates technical, but that's far easier to
> > > do on a low traffic list; obviously, I realise that style of argument
> > > doesn't suit everyone, so it's not a standard of behaviour I'd like to
> > > see universally imposed.  In fact, I've got to say that I wouldn't like
> > > to see *any* behaviour standard imposed ... they're all basically cover
> > > for power plays (or soon get abused as power plays); the only real way
> > > to display leadership on behaviour standards is by example not by fiat.
> > 
> > OK, I am stupid enough to take a stab at this...
> > 
> > 1.	Does the Linux kernel community's health depend on the occasional
> > 	rant?  [My guess is that we simply have no way of knowing.
> > 	That said, I would be interested in hearing specific examples
> > 	of open-source communities that are as doing as well as is the
> > 	Linux community and that live within stricter social mores.
> > 	Cue arguments about exactly what "doing well" means...]
> > 
> > 2.	Could the Linux kernel community's health be improved by banning
> > 	the occasional rant?  [Again, I don't believe that we have any
> > 	way of knowing.]
> > 
> > 3.	Is there some reasonable way to accommodate a wide range of
> > 	styles of interaction within the Linux community?  [I hope that
> > 	the answer is "yes", but it probably becomes impossible if you
> > 	add the qualifier "that everyone is happy with".]
> > 
> > 4.	If there is some reasonable way to accommodate a wide range
> > 	of styles of interaction within the Linux community, can this
> > 	be done globally, or does this require that people who prefer a
> > 	specific style confine themselves to portions of the community
> > 	that practice that specific style?  [As I grow older, I become
> > 	increasingly pessimistic about the possibility of keeping everyone
> > 	happy, but who knows?]
> > 
> > For whatever it is worth...
> 
> Well, you have friends in acadaemia, perhaps there might be an
> interesting study here.  If you consider the management style of the
> kernel, does it enable contributions from a broader range of people than
> would be tolerated in industry?  Industry has a problem with what
> managers like to call "brilliant jerks" people who have a well
> recognised talent but who cannot be controlled (at least by the
> aforementioned managers) and become corrosive to the team (do we
> actually manage to make use of these people in the kernel?).  They also
> tend to have a problem at the bottom end: those who are just about OK at
> their jobs; certainly not bad enough to be fired but whom they'd dearly
> love to replace with better workers (does the attitude in the kernel
> tend to discourage these types?)
> 
> It's probably less relevant to the discussion at hand, but I'd be
> curious to see the results.  Assuming they say that we do have a higher
> output per developer, the next study could investigate why this is ...

I do like your problem statement better than mine, but I must add that
I have come across people who are much more "outspoken" in proprietary
projects than I have seen on LKML.  Sorry, no quotes via email, even
private email.  Face-to-face verbal only for that level of nastiness.

Most of my friends in academia are in computer science, but I have come
across a few business-school types.  Is this something that LF would be
interested in allowing me to place its name behind?

Also, such a study would require some interaction with the researchers,
should any be interested.  Would people be willing to be interviewed,
either by phone or email?  Or would such a study need to content itself
with analysis of email archives and online news sites?

							Thanx, Paul

Re: [ATTEND] How to act on LKML

[Guenter Roeck]

On Wed, Jul 17, 2013 at 07:40:43AM -0700, Sarah Sharp wrote:

[ ... ]
> 
> The result: 75% of their developers are women.  If you give a flying
> fuck about diversity, and want to attract women to your open source

The f word is considered highly offensive in some cultures. Granted its use is
now far more spread than it used to be, but it seems interesting to me that you
of all people use a word which I personally would never use at all, much less
in front of a woman. Sounds like a contradiction to me, especially when you use
it while arguing for a more civil discussion.

Do you think you need to use that word to make a point ? If so, why do you want
to take that right away from others ?

Guenter

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Sarah Sharp]

On Wed, Jul 17, 2013 at 07:42:44PM +0100, Al Viro wrote:
> On Wed, Jul 17, 2013 at 06:56:16PM +0100, Stefano Stabellini wrote:
> 
> > Abuse is never justified, I hope that's clear for everybody.
> 
> Depends on details of your definition of abuse.
> 
> > So we are down to the definition of verbal abuse.
> > The Oxford dictionary gives me:
> > 
> > "speak to (someone) in an insulting and offensive way"
> 
> Insufficient details to tell if the statement above is correct.
> Insulting and offensive to *whom*?

It's not helpful to look at a dictionary definition of verbal abuse,
because it's much too short.

Here's a much longer description of verbally abusive behaviors:

http://outofthefog.net/CommonBehaviors/VerbalAbuse.html

Key ones that apply to LKML communications:  belittlement, demeaning
statements, hysteria, name-calling, raging and violent statements, and
mocking sarcasm.

Sarah Sharp

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 4510 bytes --]

On Wed, 2013-07-17 at 11:51 -0700, Sarah Sharp wrote:
> No, it's actually some of the comments I've received that bother me.
> For example, I would never want to deal with the misogynist troll,
> Lubin, EVER again.

It surprises me to see you calling someone names like that, Sarah. It
seems to be contrary to the request that you are making of others.

> http://permalink.gmane.org/gmane.linux.usb.general/42482

Perhaps I'm missing some context, but I'm a little confused. Did you
really complain at him *merely* because he used the phrase 'old boys
club'?

That phrase is *not* about the gender of the participants, it's about
nepotism and exclusion of non-members. Men are just as excluded by the
"old boys network" of that phrase, as women are. He's talking about
*himself* being excluded, as far as I can tell. At least in places.

To complain that he was being sexist, just because he used that phrase,
was just *WRONG*.

That was *absolutely* not what he was talking about. You appeared to
bring gender (and gender discrimination) into a conversation where it
was completely out of place and inappropriate to do so.

Sarah, it may have escaped your attention that some words and phrases
which are common in the English language contain words which appear to
be gender-specific. But that *doesn't* make them sexist. It makes no
more sense to harangue this person for his use of the phrase 'old boys
club', than it would to harangue someone for saying 'mankind' instead of
'peoplekind'.

> "You may be seen as a liability by Intel preaching "feminism" on a
> public forum.  From their point of view: will you play the gender card
> on them.  Here is what you did: Instead of realizing that I was being
> _very_ sympathetic to a more diverse Linux development environment by
> using the phrase "the old boys club", you pretended to take offense, not
> realizing you're in fact becoming a liability.  That's okay. Honest
> mistake."
>
> Telling me my job at Intel is in jeopardy because I'm complaining about
> sexist statements is a threat.  It's verbal abuse, and I won't take it.
> I shouldn't have to put up with these kinds of statements and personal
> attacks.

It's not verbal abuse, and it's not an attack. He's suggesting that if
you jump at shadows and make inappropriate complaints, you may make your
employer wary because they might be concerned that you may do the same
thing to *their* detriment. Knowing your employer as I do, I think he's
probably wrong — but I certainly don't think it was a personal attack.

Unless that message came from someone inside your employer (and probably
in your management chain), it's hard to interpret it as a 'threat'. It's
just misplaced, misguided, "personal advice" being offered to make a
point.

You gave plenty of examples earlier of stuff which *was* completely
inappropriate and personal abuse. This isn't one of them, and it
detracts from your position.

Sarah, if you're going to ask us to change our behaviour to accommodate
those who are unable to cope with our normal day-to-day communication,
then I think you need to be careful to retain your credibility by
practising what you preach, and by making sure that there *is* merit in
anything you do complain about.

There *is* plenty to complain about, certainly, without also jumping at
shadows and effectively performing an ad hominem on yourself by doing
so.

When you say that you want us to avoid personal abuse and attacks,
that's fine and I think everyone can fairly much agree. But it looks
like you have a very different definition of what 'abuse' and 'attacks'
actually are, too.

I think that's largely where the understanding breaks down in this
discussion.

I support efforts to ensure civility and encourage a more diverse
participation in our community. But when I see examples like this one, I
worry about what it might lead to. I fear that it might end up being
taken *too* far, and that makes me reluctant to support it — I fear that
we'll end up on a slippery slope to a world where I'll end up being
excluded because someone will take offence at me simply using the common
phrases and idioms of the language I grew up with. And the offence which
is drawn will be *so* random and arbitrary and unpredictable, like the
alleged 'sexism' in 'old boys club' above, that I'll be fearful of
saying *anything*, ever.

I don't think I'm the only one who has that reaction.

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]

Re: open conflicts vs. hidden conflicts (was: [ 00/19] 3.10.1-stable review)

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 2578 bytes --]

On Wed, 17 Jul 2013 20:14:40 +0200 Ingo Molnar <mingo@kernel.org> wrote:
 
> 1)
> 
> Your notion that conflicts and insults somehow hurt group cooperation is 
> wrong. It is a scientific fact that open conflict _helps_ cooperation 
> while hidden conflict hurts it.

I don't think anyone is seriously suggesting that open conflict is a bad
thing are they?
I don't object to reminding everyone that conflict can be healthy and
valuable, but is seems to miss the main point of this discussion(*).

> 
> 2)
> 
> Your notion that insults are harmful because they 'hurt' is misleading to 
> such a level that it's almost wrong.
> 
> Insults do hurt of course, but that argument misses the full context: in 
> real life the typical substitute for an avoided open conflict is not 
> singing kumbaya around the camp fire, but _hidden_ conflict.

Open conflict != insults.

Certainly there is an overlap, but it is quite possible to engage in open
conflict without being deliberately insulting.   The appropriate alternate to
insults is not "hidden conflict" but rather "civil bluntness".

So you appear to be to be drawing a false distinction here.

(I certainly agree that hidden conflict is bad)

> 
> 3)
> 
> I couldn't cite a single example where Linus flamed me unprovoked, 
> unjustified, just for the sake of letting off steam or any other petty 
> reason. I've not seen Linus flame newbies and I've not seen him 
> micro-manage people over unimportant details.
> 
> In the large majority of colorful flames the flame was over something that 
> _matters to the kernel_ - and heck do I prefer a top level maintainer who 
> cares and who is honest, over someone who is indifferent or sloppy ...

If it is something really important (which this stuff is), then surely it is
important enough to make the effort to communicate it effectively.
Being emotional is OK and even getting heated about something you care a lot
about.  But that doesn't justify directing your heat at others.

An extremely good rule of thumb for when you are communicating emotionally is
to make "I" statements.

  I don't give a #&*%$ if it fixes a bug - it introduces a @*#$$ regression
  and that @#$*%@ is not acceptable. Ever.

is, in my mind, perfectly acceptable.  Saying

  You've $%^@$% done it again.

is not helpful.

http://en.wikipedia.org/wiki/I-message


(*) One of the amusing things about this whole discussion is that different
people seem that have very different ideas about what the core issue really
is.

NeilBrown


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ATTEND] How to act on LKML

[Randy Dunlap]

On 07/17/13 15:02, Guenter Roeck wrote:
> On Wed, Jul 17, 2013 at 07:40:43AM -0700, Sarah Sharp wrote:
> 
> [ ... ]
>>
>> The result: 75% of their developers are women.  If you give a flying
>> fuck about diversity, and want to attract women to your open source
> 
> The f word is considered highly offensive in some cultures. Granted its use is
> now far more spread than it used to be, but it seems interesting to me that you
> of all people use a word which I personally would never use at all, much less
> in front of a woman. Sounds like a contradiction to me, especially when you use
> it while arguing for a more civil discussion.
> 
> Do you think you need to use that word to make a point ? If so, why do you want
> to take that right away from others ?

Thank you for your comment.  (seriously)

and Dave Miller's as well.


-- 
~Randy

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Guenter Roeck]

On Wed, Jul 17, 2013 at 09:03:35AM -0400, Steven Rostedt wrote:
> On Wed, 2013-07-17 at 13:30 +0100, Ricardo Ferreira wrote:
> > Slashdot is just a cesspool of trolls, not a good comparison.
> 
> Point taken.
> 
> I posted this privately, and I think I'll repost it here. I need to
> modify it a bit as it wasn't meant to be public.
> 
> 
> When I started sending patches to LKML it was not the cursing I was
> afraid of, it was the possibility of top notch developers pointing out
> my flaws. Linux is intimidating not because it can be harsh, but because
> its the big league. You are posting code not only to the world but also
> to some of the best programmers on the planet, and frankly, that's
> really scary. And I think that's the real reason people who are shy tend
> not to want to participate. They use the harshness of LKML as an excuse,
> but I think it's really that they may be insecure about their own work
> and how it will compare with the best of the best.
> 
> Both my wife and I have done karate for decades. My wife has even won a
> national tournament. She can do demos without a problem, but when she
> has to get up in front of other top black belts, she's a nervous wreck.
> She's her biggest critic, but she tends to know that when performing in
> front of people as good as she is, or better, they can see her flaws as
> much as she can. That is intimidating.
> 
> The point I'm making is that we need to find out what is preventing good
> developers from joining the Linux community. Is it really the harshness
> of the project, or is it because we expect you to have the best code,
> and you will not be accepted if you are not that good. And I do not want
> people joining that are not good programmers.
> 
Preventing good developers from joining - I don't know. Maybe there just
are not that many.

I have heard lots of reasons for not paricipating in open source development.
The "official" stated reason is often around "not exposing our IP", where
"IP" is sometimes declared to be each line of code. Another is "we don't want
to help our competitors".

Personally I believe that being afraid is only part of the picture. Good
developers should ultimately know that their code is good, and not be afraid
to show it (or find a mentor to encourage them). However, I have to say that
that much of the code I have seen in my life is _not_ good, or crap as is
referred to by many in the Linux community. To some degree includes my own code -
if I encounter code I have written ten years ago, I often think "did I really
write this crap ?".  I think _that_ is a key reason for people not
participating - they are afraid that their code might be exposed as crap.
A corrolary of that might be that some companies don't want their customers
to see how bad the code is they are shipping to them.

> The answer is not to bash Linus into being a nice guy (which seems to be
> what Sarah's trying to do), but we can get mentors or even "scouts" to
> look for people of talent and help them get into the community. What
> those people need is not a nicer LKML that will let mediocre developers
> in, but someone that recognizes their talent and encourages them to
> join, by reinforcing to them how good of a developer they are. I've
> helped people this way. Talented programmers that were unsure of
> themselves, and they have done extremely well in our community.
> 
Excellent summary. I absolutely agree.

Thanks,
Guenter

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Ramkumar Ramachandra]

Sarah Sharp wrote:
> https://picasaweb.google.com/116960357493251979546/Trolls#5901298464591248626
> https://picasaweb.google.com/116960357493251979546/Trolls#5901288095984358098
>
> On my blog, here's some choice comments, mostly asking me to quit kernel
> development, along with more than a few misogynist comments:

So it's a publicity stunt then.  That is the only rational
explanation, because the alternative explanation is that you're trying
to tame the internet ;)

Another flash in the pan: this whole event (and you) will be erased
from everyone's memories in a few weeks.  Okay, maybe a few months if
you get fired from SendGrid.

You're better than that.  Think calmly, and focus your attention on
making a long-term impact.  Hint: it's not going to happen by arguing
endlessly about the same thing.

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Paul E. McKenney]

On Wed, Jul 17, 2013 at 03:49:23PM -0700, Randy Dunlap wrote:
> On 07/17/13 15:02, Guenter Roeck wrote:
> > On Wed, Jul 17, 2013 at 07:40:43AM -0700, Sarah Sharp wrote:
> > 
> > [ ... ]
> >>
> >> The result: 75% of their developers are women.  If you give a flying
> >> fuck about diversity, and want to attract women to your open source
> > 
> > The f word is considered highly offensive in some cultures. Granted its use is
> > now far more spread than it used to be, but it seems interesting to me that you
> > of all people use a word which I personally would never use at all, much less
> > in front of a woman. Sounds like a contradiction to me, especially when you use
> > it while arguing for a more civil discussion.
> > 
> > Do you think you need to use that word to make a point ? If so, why do you want
> > to take that right away from others ?
> 
> Thank you for your comment.  (seriously)
> 
> and Dave Miller's as well.

The USA social conventions have changed quite significantly over the past
50 years, haven't they?  But that is OK, the younger people on this list
will likely have the opportunity to experience far greater changes over
the next 50 years, especially given increasing fractions of people's
life experiences being publicly recorded.  It would be interesting to
see how they react, but I probably won't be around to witness it.  ;-)

							Thanx, Paul

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Guenter Roeck]

On Wed, Jul 17, 2013 at 04:08:31PM -0700, Paul E. McKenney wrote:
> On Wed, Jul 17, 2013 at 03:49:23PM -0700, Randy Dunlap wrote:
> > On 07/17/13 15:02, Guenter Roeck wrote:
> > > On Wed, Jul 17, 2013 at 07:40:43AM -0700, Sarah Sharp wrote:
> > > 
> > > [ ... ]
> > >>
> > >> The result: 75% of their developers are women.  If you give a flying
> > >> fuck about diversity, and want to attract women to your open source
> > > 
> > > The f word is considered highly offensive in some cultures. Granted its use is
> > > now far more spread than it used to be, but it seems interesting to me that you
> > > of all people use a word which I personally would never use at all, much less
> > > in front of a woman. Sounds like a contradiction to me, especially when you use
> > > it while arguing for a more civil discussion.
> > > 
> > > Do you think you need to use that word to make a point ? If so, why do you want
> > > to take that right away from others ?
> > 
> > Thank you for your comment.  (seriously)
> > 
> > and Dave Miller's as well.
> 
> The USA social conventions have changed quite significantly over the past
> 50 years, haven't they?  But that is OK, the younger people on this list
> will likely have the opportunity to experience far greater changes over
> the next 50 years, especially given increasing fractions of people's
> life experiences being publicly recorded.  It would be interesting to
> see how they react, but I probably won't be around to witness it.  ;-)
> 
My kids use the word all the time, and look at me with an odd face if I point out
that it is not a nice word to use (for me). Several people I know and respect
seem to be unable to say a sentence without using it. So, yes, I am aware that
times are changing, and that my cultural context is different than that of the
culture I am living in. But that isn't the point here.

Guenter

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Felipe Contreras]

On Wed, Jul 17, 2013 at 5:24 PM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
> On Wed, Jul 17, 2013 at 07:42:44PM +0100, Al Viro wrote:
>> On Wed, Jul 17, 2013 at 06:56:16PM +0100, Stefano Stabellini wrote:
>>
>> > Abuse is never justified, I hope that's clear for everybody.
>>
>> Depends on details of your definition of abuse.
>>
>> > So we are down to the definition of verbal abuse.
>> > The Oxford dictionary gives me:
>> >
>> > "speak to (someone) in an insulting and offensive way"
>>
>> Insufficient details to tell if the statement above is correct.
>> Insulting and offensive to *whom*?
>
> It's not helpful to look at a dictionary definition of verbal abuse,
> because it's much too short.
>
> Here's a much longer description of verbally abusive behaviors:
>
> http://outofthefog.net/CommonBehaviors/VerbalAbuse.html

That definition starts with this:

"Any kind of repeated pattern of inappropriate, derogatory or
threatening speech directed at one individual by another."

The key word being *REPEATED*. I don't see Linus *repeatedly*
insulting Mauro (or any other developer), under that definition, it's
not verbal abuse.

I don't like that definition, but even in that one your claim doesn't stand.

-- 
Felipe Contreras

Re: [ 00/19] 3.10.1-stable review

[Thomas Gleixner]

On Mon, 15 Jul 2013, Sarah Sharp wrote:
> On Mon, Jul 15, 2013 at 12:07:56PM -0700, Linus Torvalds wrote:
> > On Mon, Jul 15, 2013 at 11:46 AM, Sarah Sharp
> > <sarah.a.sharp@linux.intel.com> wrote:
> > >
> > > Bullshit.  I've seen you be polite, and explain to clueless maintainers
> > > why there's no way you can revert their merge that caused regressions,
> > > and ask them to fit it without resorting to tearing them down
> > > emotionally:
> > 
> > Oh, I'll be polite when it's called for.
> > 
> > But when people who know better send me crap, I'll curse at them.
> > 
> > I suspect you'll notice me cursing *way* more at top developers than
> > random people on the list. I expect more from them, and conversely
> > I'll be a lot more upset when they do something that I really think
> > was not great.
> > 
> > For example, my latest cursing explosion was for the x86 maintainers,
> > and it comes from the fact that I *know* they know to do better. The
> > x86 tip pulls have generally been through way more testing than most
> > other pulls I get (not just compiling, but even booting randconfigs
> > etc). So when an x86 pull request comes in that clearly missed that
> > expected level of quality, I go to town.
> >
> Good lord.  So anyone that is one of your "top maintainers" could be
> exposed to your verbal abuse just because they "should have known
> better"?

I'm one of the "victims" of Linus' latest "verbal abuse". :)
 
Just for the record. I got grilled by Linus several times over the
last years and I can't remember a single instance where it was
unjustified. When I see such a mail in my inbox, I know that I fucked
up royally and all I do is to figure out what I broke this time and
fix it. I don't give a rat's ass about his "abusive" language. See
below.

> exposed to your verbal abuse just because they "should have known
> better"?

You know what "should have known better" stands for?

    It stands for violating trust.

Linus simply has to trusts his top level maintainers, because he
cannot review, audit and check 10k patches which flow into his tree
every merge window himself.

So if he finds out that someone who has his ultimate trust sends him a
pile of crap, he tells that person in his own unmisunderstandable way
that he's not amused.

> You know what the definition of an abuser is?  Someone that seeks out
> victims that they know will "just take it" and keep the abuse "between
> the two of them".  They pick victims that won't fight back or report the
> abuse.

IOW, I'm a typical victim of abuse.

Let me clarify that.

The person who gets away with picking me for this kind of abuse has
not been born yet. And Linus knows very well, that he gets the full
pack back from me (in some different form of "abusive language") if he
yelled at me for no reason. It's documented out there including his
apologies.

So if you talk about abuse, then you need an abuser and a victim. So
your argumentation falls flat because there is no victim.

I do not care about his swear words and rants at all, because I know
that it makes him feel better.

     That's a cultural thing.

Where I grew up it's part of the culture to explode, let off steam and
then go and have a beer together. I strongly believe this prevents
gastric ulcer and keeps you honest. Linus and I have this kind of
relationship. We respect each other, we trust each other and when one
side fucks up we yell at each other and then meet at the bar for a
drink.

Linus did NOT abuse me in his latest rant. He simply told me in a very
strong language that he's grumpy because I violated his trust. And
that's legitimate. It's also legitimate to do that in public because
it documents that the top level maintainers are not impeccable. And it
sets a clear expectation bar for those who want to become maintainers
of any level.

Aside of that I completely agree with Linus, that this policital
correctness crusades are merily creating more subtle and hard to fight
forms of real abuse.

I observe that every other day in big corporates, which have written
down code of conducts and a gazillion of rules for interaction; they
just foster dishonesty and other fallacies.

I really prefer the honest slap from Linus than dealing with people
who signed and "comply" to some code of conduct and stab you in your
back wherever they can.

If you can point me to a single instance of Linus "abusing" someone
who is not one of his trusted persons, who really should be able to
deal with that, or someone who did not provoke him to go into rant
mode, then I'm all on your side.

Aside of that, I agree that Linus could achieve the same effect by
using a different (more palatable to you) language, but that's a
different story.


Thanks,

	tglx

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Paul E. McKenney]

On Wed, Jul 17, 2013 at 04:19:34PM -0700, Guenter Roeck wrote:
> On Wed, Jul 17, 2013 at 04:08:31PM -0700, Paul E. McKenney wrote:
> > On Wed, Jul 17, 2013 at 03:49:23PM -0700, Randy Dunlap wrote:
> > > On 07/17/13 15:02, Guenter Roeck wrote:
> > > > On Wed, Jul 17, 2013 at 07:40:43AM -0700, Sarah Sharp wrote:
> > > > 
> > > > [ ... ]
> > > >>
> > > >> The result: 75% of their developers are women.  If you give a flying
> > > >> fuck about diversity, and want to attract women to your open source
> > > > 
> > > > The f word is considered highly offensive in some cultures. Granted its use is
> > > > now far more spread than it used to be, but it seems interesting to me that you
> > > > of all people use a word which I personally would never use at all, much less
> > > > in front of a woman. Sounds like a contradiction to me, especially when you use
> > > > it while arguing for a more civil discussion.
> > > > 
> > > > Do you think you need to use that word to make a point ? If so, why do you want
> > > > to take that right away from others ?
> > > 
> > > Thank you for your comment.  (seriously)
> > > 
> > > and Dave Miller's as well.
> > 
> > The USA social conventions have changed quite significantly over the past
> > 50 years, haven't they?  But that is OK, the younger people on this list
> > will likely have the opportunity to experience far greater changes over
> > the next 50 years, especially given increasing fractions of people's
> > life experiences being publicly recorded.  It would be interesting to
> > see how they react, but I probably won't be around to witness it.  ;-)
> > 
> My kids use the word all the time, and look at me with an odd face if I point out
> that it is not a nice word to use (for me). Several people I know and respect
> seem to be unable to say a sentence without using it. So, yes, I am aware that
> times are changing, and that my cultural context is different than that of the
> culture I am living in. But that isn't the point here.

Heh!  If I were to ask each of the N participants in this thread what
the point was, would I get fewer than N different answers?  ;-)

							Thanx, Paul

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Benjamin Herrenschmidt]

On Wed, 2013-07-17 at 10:14 +0400, James Bottomley wrote:
> > OK, I am stupid enough to take a stab at this...
> > 
> > 1.    Does the Linux kernel community's health depend on the occasional
> >       rant?  [My guess is that we simply have no way of knowing.
> >       That said, I would be interested in hearing specific examples
> >       of open-source communities that are as doing as well as is the
> >       Linux community and that live within stricter social mores.
> >       Cue arguments about exactly what "doing well" means...]

My little personal opinion (that nobody probably cares about :-) is that
the occasional Linus rant is a good thing. It keeps people like me in
check :-)

More seriously, the rant when I screw up is generally deserved, and the
"idea" of the possible rant (I prefer not using threat) is actually a
strong motivator to get things right.

Ie. It's a *very good* barrier against maintainers sliding into
sloppyness. Really, it works. At least with me.

It's easy to take things a bit too much for granted, especially when you
maintain your own little corner of the world.

Cheers,
Ben.

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Benjamin Herrenschmidt]

On Wed, 2013-07-17 at 11:51 -0700, Sarah Sharp wrote:
> Here's a gem from a senior software developer at Nvidia:
> https://picasaweb.google.com/116960357493251979546/Trolls#5901298464591248626
> 
> And another email from a software developer in Portland, where I live:
> https://picasaweb.google.com/116960357493251979546/Trolls#5901288095984358098
> 
> On my blog, here's some choice comments, mostly asking me to quit kernel
> development, along with more than a few misogynist comments:
> 
> "You volunteered to help out on the Linux journey. He never volunteered
> to care for your feelings, nor did anyone else. It’s an opt-in community
> and you can always opt out at any time. Caveat emptor."
> 
> "You’re no one compared to Linus. Start being Alan Cox or Theodore T’so
> first to criticize him for his behaviour."

There is a whole army of idiots out there, we know that. We aren't going to
fix *that*. Was any of the above actually a *relevant* person as part of
our community ? Because non of what we do, say, document, decide, etc...
here will change those idiots.

Cheers,
Ben.

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[CAI Qian]

----- Original Message -----
> From: "Sarah Sharp" <sarah.a.sharp@linux.intel.com>
> To: "CAI Qian" <caiqian@redhat.com>
> Cc: "Trond Myklebust" <Trond.Myklebust@netapp.com>, "Ric Wheeler" <ricwheeler@gmail.com>, "David Lang"
> <david@lang.hm>, ksummit-2013-discuss@lists.linuxfoundation.org, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
> "Darren Hart" <dvhart@linux.intel.com>, "Ingo Molnar" <mingo@kernel.org>, "Olivier Galibert" <galibert@pobox.com>,
> "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "stable" <stable@vger.kernel.org>, "Linus Torvalds"
> <torvalds@linux-foundation.org>, "Willy Tarreau" <w@1wt.eu>
> Sent: Wednesday, July 17, 2013 10:48:49 PM
> Subject: Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML
> 
> On Wed, Jul 17, 2013 at 03:36:36AM -0400, CAI Qian wrote:
> > > On Tue, 2013-07-16 at 19:31 -0400, Ric Wheeler wrote:
> > > > On 07/16/2013 07:12 PM, Sarah Sharp wrote:
> > > > > On Tue, Jul 16, 2013 at 06:54:59PM -0400, Steven Rostedt wrote:
> > > > >> On Tue, 2013-07-16 at 15:43 -0700, Sarah Sharp wrote:
> > > > > In order to make our community better, we need to figure out where
> > > > > the
> > > > > baseline of "good" behavior is.  We need to define what behavior we
> > > > > want
> > > > > from both maintainers and patch submitters.  E.g. "No regressions"
> > > > > and
> > > > > "don't break userspace" and "no personal attacks".  That needs to be
> > > > > written down somewhere, and it isn't.  If it's documented somewhere,
> > > > > point me to the file in Documentation.  Hint: it's not there.
> > > > >
> > > > > That is the problem.
> > > > >
> > > > > Sarah Sharp
> > > > 
> > > > The problem you are pointing out - and it is a problem - makes us less
> > > > effective
> > > > as a community.
> > > 
> > > Not really. Most of the people who already work as part of this
> > > community are completely used to it. We've created the environment, and
> > > have no problems with it.
> > > 
> > > Where it could possibly be a problem is when it comes to recruiting
> > > _new_ members to our community. Particularly so given that some
> > > journalists take a special pleasure in reporting particularly juicy
> > > comments and antics. That would tend to scare off a lot of gun-shy
> > > newbies.
> > >
> > > On the other hand, it might tend to bias our recruitment toward people
> > > of a more "special" disposition. Perhaps we finally need the services of
> > > a social scientist to help us find out...
> >
> > Does that sound like there are not going to have enough direct/thick skin
> > new kernel developers around to maintain the future Linux community? Maybe
> > just need a better pipeline for people comfortable for this culture?
> 
> No, we don't need a better pipeline for people who can "put up with
> shit".  We need a better pipeline for people who can work together
> civilly, and still get shit done.
> 
> I'm working on getting a pipeline of women into kernel development,
> through the FOSS Outreach Program for Women.  They slowly get introduced
> to Linux development culture, starting with a very friendly separate
> mailing list and IRC channel, and finally moving to work with a kernel
> mentor on a bigger project on the main Linux kernel development lists.
> We have seven women participating this round, and I suspect we'll have
> even more the next round.
> 
> So deal with it.  You're going to have a lot more women in the kernel
> community, and not all of them will be willing to put up with verbal
> abuse.  If you want to attract top talent that also happen to be women
> or racial minorities, the verbal abuse needs to stop.
Maybe we need something like this?
http://us.battle.net/en/community/conduct
> 
> Sarah Sharp
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [ 00/19] 3.10.1-stable review

[CAI Qian]

----- Original Message -----
> From: "Thomas Gleixner" <tglx@linutronix.de>
> To: "Sarah Sharp" <sarah.a.sharp@linux.intel.com>
> Cc: "Linus Torvalds" <torvalds@linux-foundation.org>, "Ingo Molnar" <mingo@kernel.org>, "Guenter Roeck"
> <linux@roeck-us.net>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "Steven Rostedt" <rostedt@goodmis.org>,
> "Dave Jones" <davej@redhat.com>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "Andrew Morton"
> <akpm@linux-foundation.org>, "stable" <stable@vger.kernel.org>, "Darren Hart" <dvhart@linux.intel.com>
> Sent: Thursday, July 18, 2013 8:42:16 AM
> Subject: Re: [ 00/19] 3.10.1-stable review
> 
> On Mon, 15 Jul 2013, Sarah Sharp wrote:
> > On Mon, Jul 15, 2013 at 12:07:56PM -0700, Linus Torvalds wrote:
> > > On Mon, Jul 15, 2013 at 11:46 AM, Sarah Sharp
> > > <sarah.a.sharp@linux.intel.com> wrote:
> > > >
> > > > Bullshit.  I've seen you be polite, and explain to clueless maintainers
> > > > why there's no way you can revert their merge that caused regressions,
> > > > and ask them to fit it without resorting to tearing them down
> > > > emotionally:
> > > 
> > > Oh, I'll be polite when it's called for.
> > > 
> > > But when people who know better send me crap, I'll curse at them.
> > > 
> > > I suspect you'll notice me cursing *way* more at top developers than
> > > random people on the list. I expect more from them, and conversely
> > > I'll be a lot more upset when they do something that I really think
> > > was not great.
> > > 
> > > For example, my latest cursing explosion was for the x86 maintainers,
> > > and it comes from the fact that I *know* they know to do better. The
> > > x86 tip pulls have generally been through way more testing than most
> > > other pulls I get (not just compiling, but even booting randconfigs
> > > etc). So when an x86 pull request comes in that clearly missed that
> > > expected level of quality, I go to town.
> > >
> > Good lord.  So anyone that is one of your "top maintainers" could be
> > exposed to your verbal abuse just because they "should have known
> > better"?
> 
> I'm one of the "victims" of Linus' latest "verbal abuse". :)
>  
> Just for the record. I got grilled by Linus several times over the
> last years and I can't remember a single instance where it was
> unjustified. When I see such a mail in my inbox, I know that I fucked
> up royally and all I do is to figure out what I broke this time and
> fix it. I don't give a rat's ass about his "abusive" language. See
> below.
> 
> > exposed to your verbal abuse just because they "should have known
> > better"?
> 
> You know what "should have known better" stands for?
> 
>     It stands for violating trust.
> 
> Linus simply has to trusts his top level maintainers, because he
> cannot review, audit and check 10k patches which flow into his tree
> every merge window himself.
> 
> So if he finds out that someone who has his ultimate trust sends him a
> pile of crap, he tells that person in his own unmisunderstandable way
> that he's not amused.
> 
> > You know what the definition of an abuser is?  Someone that seeks out
> > victims that they know will "just take it" and keep the abuse "between
> > the two of them".  They pick victims that won't fight back or report the
> > abuse.
> 
> IOW, I'm a typical victim of abuse.
> 
> Let me clarify that.
> 
> The person who gets away with picking me for this kind of abuse has
> not been born yet. And Linus knows very well, that he gets the full
> pack back from me (in some different form of "abusive language") if he
> yelled at me for no reason. It's documented out there including his
> apologies.
> 
> So if you talk about abuse, then you need an abuser and a victim. So
> your argumentation falls flat because there is no victim.
Could victim be someone else in the future since it is an example that
people may follow?
http://en.wikipedia.org/wiki/Silvio_Berlusconi_underage_prostitution_charges
It called "abuse of office" or abuse of the power.
> 
> I do not care about his swear words and rants at all, because I know
> that it makes him feel better.
> 
>      That's a cultural thing.
> 
> Where I grew up it's part of the culture to explode, let off steam and
> then go and have a beer together. I strongly believe this prevents
> gastric ulcer and keeps you honest. Linus and I have this kind of
> relationship. We respect each other, we trust each other and when one
> side fucks up we yell at each other and then meet at the bar for a
> drink.
> 
> Linus did NOT abuse me in his latest rant. He simply told me in a very
> strong language that he's grumpy because I violated his trust. And
> that's legitimate. It's also legitimate to do that in public because
> it documents that the top level maintainers are not impeccable. And it
> sets a clear expectation bar for those who want to become maintainers
> of any level.
> 
> Aside of that I completely agree with Linus, that this policital
> correctness crusades are merily creating more subtle and hard to fight
> forms of real abuse.
> 
> I observe that every other day in big corporates, which have written
> down code of conducts and a gazillion of rules for interaction; they
> just foster dishonesty and other fallacies.
> 
> I really prefer the honest slap from Linus than dealing with people
> who signed and "comply" to some code of conduct and stab you in your
> back wherever they can.
> 
> If you can point me to a single instance of Linus "abusing" someone
> who is not one of his trusted persons, who really should be able to
> deal with that, or someone who did not provoke him to go into rant
> mode, then I'm all on your side.
> 
> Aside of that, I agree that Linus could achieve the same effect by
> using a different (more palatable to you) language, but that's a
> different story.
> 
> 
> Thanks,
> 
> 	tglx
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Wed, 2013-07-17 at 23:16 -0400, CAI Qian wrote:

> > So if you talk about abuse, then you need an abuser and a victim. So
> > your argumentation falls flat because there is no victim.
> Could victim be someone else in the future since it is an example that
> people may follow?
> http://en.wikipedia.org/wiki/Silvio_Berlusconi_underage_prostitution_charges
> It called "abuse of office" or abuse of the power.

Wow! You are now comparing Linus to a Prime Minister that has paid
underage prostitutes for sex?

That's pretty low.

What Linus does is not an abuse of power, it's a protection of his baby.
He created Linux, and although today he's not the one writing the code,
he is ultimately the front man responsible for the kernel.

Think about it. If Linux does something horrible, Linus is the one that
takes the most blame. That's a HUGE responsibility. Linus has the most
to lose if Linux becomes crap.

Not only does Linus have to check on code, he must also dictate policy.
Which means dealing with different people, and how they work. If someone
gets lazy and uses his trust to get something whacky in, Linus takes the
blame for it if that happens. Thus, to prevent people from taking
advantage of his trust, he has to be hard on them to make sure he can
keep their trust.

Linus takes his job seriously. He may joke and name his kernel after
90's operating systems, but that's just to make the job more fun. But to
keep the job, he needs to be a hard ass.

The few times he's yelled at me, he always did it with a bit of comedy
and wit. That makes the harsh yelling not so bad, and I actually got a
chuckle out of it. But I also took the harsh yelling in a way that I had
better not do that again.

This is the big leagues folks. You think major league baseball managers
are nice to their players?

"You just walked 4 players. That's not good. Keep this up I'll have to
take you out off the team".

  vs

"What the f*ck is wrong with you. Get you head out of your @ss and start
throwing the ball over the God damn plate before I throw your @ss out of
this field!"

They both relay basically the same thing. The first one is nice and
polite but states that bad things will happen if they keep it up. The
second is quite harsh (although never calling the person a name), and
will probably wake the person up and change his game. Which one of those
tones do you think successful baseball managers use?

Sometimes tone *does* matter. You want quality from the top maintainers,
and they start to slack, you can't just treat them like this is a grade
school sport. Results matter. You want them to understand that this is
serious and cursing someone out gives that person that feeling.

-- Steve

Re: [ 00/19] 3.10.1-stable review

[CAI Qian]

----- Original Message -----
> From: "Steven Rostedt" <rostedt@goodmis.org>
> To: "CAI Qian" <caiqian@redhat.com>
> Cc: "Thomas Gleixner" <tglx@linutronix.de>, "Sarah Sharp" <sarah.a.sharp@linux.intel.com>, "Linus Torvalds"
> <torvalds@linux-foundation.org>, "Ingo Molnar" <mingo@kernel.org>, "Guenter Roeck" <linux@roeck-us.net>, "Greg
> Kroah-Hartman" <gregkh@linuxfoundation.org>, "Dave Jones" <davej@redhat.com>, "Linux Kernel Mailing List"
> <linux-kernel@vger.kernel.org>, "Andrew Morton" <akpm@linux-foundation.org>, "stable" <stable@vger.kernel.org>,
> "Darren Hart" <dvhart@linux.intel.com>
> Sent: Thursday, July 18, 2013 11:47:34 AM
> Subject: Re: [ 00/19] 3.10.1-stable review
> 
> On Wed, 2013-07-17 at 23:16 -0400, CAI Qian wrote:
> 
> > > So if you talk about abuse, then you need an abuser and a victim. So
> > > your argumentation falls flat because there is no victim.
> > Could victim be someone else in the future since it is an example that
> > people may follow?
> > http://en.wikipedia.org/wiki/Silvio_Berlusconi_underage_prostitution_charges
> > It called "abuse of office" or abuse of the power.
> 
> Wow! You are now comparing Linus to a Prime Minister that has paid
> underage prostitutes for sex?
I apologize that this leads to misunderstanding. It was just happened to
read the news that underage child does not feel like she is a victim
either while the law still think that is an abuse. Another example, those
BBC child abusers took ages to track down that probably because those
children did not feel victims at that time either. 

Please don't get me wrong. I did neither compare Linus to those child abusers
nor Thomas to those children. I simply pointed out there is also some common
sense need to consider.
> 
> That's pretty low.
> 
> What Linus does is not an abuse of power, it's a protection of his baby.
> He created Linux, and although today he's not the one writing the code,
> he is ultimately the front man responsible for the kernel.
> 
> Think about it. If Linux does something horrible, Linus is the one that
> takes the most blame. That's a HUGE responsibility. Linus has the most
> to lose if Linux becomes crap.
> 
> Not only does Linus have to check on code, he must also dictate policy.
> Which means dealing with different people, and how they work. If someone
> gets lazy and uses his trust to get something whacky in, Linus takes the
> blame for it if that happens. Thus, to prevent people from taking
> advantage of his trust, he has to be hard on them to make sure he can
> keep their trust.
> 
> Linus takes his job seriously. He may joke and name his kernel after
> 90's operating systems, but that's just to make the job more fun. But to
> keep the job, he needs to be a hard ass.
> 
> The few times he's yelled at me, he always did it with a bit of comedy
> and wit. That makes the harsh yelling not so bad, and I actually got a
> chuckle out of it. But I also took the harsh yelling in a way that I had
> better not do that again.
> 
> This is the big leagues folks. You think major league baseball managers
> are nice to their players?
> 
> "You just walked 4 players. That's not good. Keep this up I'll have to
> take you out off the team".
> 
>   vs
> 
> "What the f*ck is wrong with you. Get you head out of your @ss and start
> throwing the ball over the God damn plate before I throw your @ss out of
> this field!"
> 
> They both relay basically the same thing. The first one is nice and
> polite but states that bad things will happen if they keep it up. The
> second is quite harsh (although never calling the person a name), and
> will probably wake the person up and change his game. Which one of those
> tones do you think successful baseball managers use?
> 
> Sometimes tone *does* matter. You want quality from the top maintainers,
> and they start to slack, you can't just treat them like this is a grade
> school sport. Results matter. You want them to understand that this is
> serious and cursing someone out gives that person that feeling.
> 
> -- Steve
> 
> 
> 

Re: [ 00/19] 3.10.1-stable review

[CAI Qian]

----- Original Message -----
> From: "Steven Rostedt" <rostedt@goodmis.org>
> To: "CAI Qian" <caiqian@redhat.com>
> Cc: "Thomas Gleixner" <tglx@linutronix.de>, "Sarah Sharp" <sarah.a.sharp@linux.intel.com>, "Linus Torvalds"
> <torvalds@linux-foundation.org>, "Ingo Molnar" <mingo@kernel.org>, "Guenter Roeck" <linux@roeck-us.net>, "Greg
> Kroah-Hartman" <gregkh@linuxfoundation.org>, "Dave Jones" <davej@redhat.com>, "Linux Kernel Mailing List"
> <linux-kernel@vger.kernel.org>, "Andrew Morton" <akpm@linux-foundation.org>, "stable" <stable@vger.kernel.org>,
> "Darren Hart" <dvhart@linux.intel.com>
> Sent: Thursday, July 18, 2013 11:47:34 AM
> Subject: Re: [ 00/19] 3.10.1-stable review
> 
> On Wed, 2013-07-17 at 23:16 -0400, CAI Qian wrote:
> 
> > > So if you talk about abuse, then you need an abuser and a victim. So
> > > your argumentation falls flat because there is no victim.
> > Could victim be someone else in the future since it is an example that
> > people may follow?
> > http://en.wikipedia.org/wiki/Silvio_Berlusconi_underage_prostitution_charges
> > It called "abuse of office" or abuse of the power.
> 
> Wow! You are now comparing Linus to a Prime Minister that has paid
> underage prostitutes for sex?
> 
> That's pretty low.
> 
> What Linus does is not an abuse of power, it's a protection of his baby.
> He created Linux, and although today he's not the one writing the code,
> he is ultimately the front man responsible for the kernel.
Surely Linus has great responsibility, but isn't that every powerful person/organizatio
could tell the same story? Berlusconi has a country to take care of; Jimmy Savile has a
television kingdom to manage; NSA needs to protect world peace etc.
> 
> Think about it. If Linux does something horrible, Linus is the one that
> takes the most blame. That's a HUGE responsibility. Linus has the most
> to lose if Linux becomes crap.
> 
> Not only does Linus have to check on code, he must also dictate policy.
> Which means dealing with different people, and how they work. If someone
> gets lazy and uses his trust to get something whacky in, Linus takes the
> blame for it if that happens. Thus, to prevent people from taking
> advantage of his trust, he has to be hard on them to make sure he can
> keep their trust.
> 
> Linus takes his job seriously. He may joke and name his kernel after
> 90's operating systems, but that's just to make the job more fun. But to
> keep the job, he needs to be a hard ass.
> 
> The few times he's yelled at me, he always did it with a bit of comedy
> and wit. That makes the harsh yelling not so bad, and I actually got a
> chuckle out of it. But I also took the harsh yelling in a way that I had
> better not do that again.
> 
> This is the big leagues folks. You think major league baseball managers
> are nice to their players?
> 
> "You just walked 4 players. That's not good. Keep this up I'll have to
> take you out off the team".
> 
>   vs
> 
> "What the f*ck is wrong with you. Get you head out of your @ss and start
> throwing the ball over the God damn plate before I throw your @ss out of
> this field!"
> 
> They both relay basically the same thing. The first one is nice and
> polite but states that bad things will happen if they keep it up. The
> second is quite harsh (although never calling the person a name), and
> will probably wake the person up and change his game. Which one of those
> tones do you think successful baseball managers use?
> 
> Sometimes tone *does* matter. You want quality from the top maintainers,
> and they start to slack, you can't just treat them like this is a grade
> school sport. Results matter. You want them to understand that this is
> serious and cursing someone out gives that person that feeling.
> 
> -- Steve
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Al Viro]

On Wed, Jul 17, 2013 at 03:24:18PM -0700, Sarah Sharp wrote:

> > > Abuse is never justified, I hope that's clear for everybody.
> > 
> > Depends on details of your definition of abuse.
[snip]
> http://outofthefog.net/CommonBehaviors/VerbalAbuse.html

"   "Always" and "Never" Statements - "Always" and "Never" Statements are
   declarations containing the words "always" or "never". They are
   commonly used but rarely true.
"

See above...  And as far as I can see in this thread, there *is* a pattern
of that by Stefano; should that be interpreted as verbal abuse?

> Key ones that apply to LKML communications:  belittlement, demeaning
> statements, hysteria, name-calling, raging and violent statements, and
> mocking sarcasm.

"   Targeted Humor, Mocking and Sarcasm - Targeted Humor is any sustained
   pattern of joking, sarcasm or mockery which is designed to reduce
   another individual's reputation in their own eyes or in the eyes of
   others.
"

s/individual's reputation/appeal of a bad idea being proposed/ and you'll
get something that is not only justified, but highly valuable.

Re: [ 00/19] 3.10.1-stable review

[H. Peter Anvin]

On 07/17/2013 09:01 PM, CAI Qian wrote:
> 
> Please don't get me wrong. I did neither compare Linus to those child abusers
> nor Thomas to those children. I simply pointed out there is also some common
> sense need to consider.
>

Actually, you did.

	-hpa

Re: [ 00/19] 3.10.1-stable review

[CAI Qian]

----- 原始邮件 -----
> 发件人: "H. Peter Anvin" <hpa@zytor.com>
> 收件人: "CAI Qian" <caiqian@redhat.com>
> 抄送: "Steven Rostedt" <rostedt@goodmis.org>, "Thomas Gleixner" <tglx@linutronix.de>, "Sarah Sharp"
> <sarah.a.sharp@linux.intel.com>, "Linus Torvalds" <torvalds@linux-foundation.org>, "Ingo Molnar" <mingo@kernel.org>,
> "Guenter Roeck" <linux@roeck-us.net>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "Dave Jones"
> <davej@redhat.com>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "Andrew Morton"
> <akpm@linux-foundation.org>, "stable" <stable@vger.kernel.org>, "Darren Hart" <dvhart@linux.intel.com>
> 发送时间: 星期四, 2013年 7 月 18日 下午 1:03:41
> 主题: Re: [ 00/19] 3.10.1-stable review
> 
> On 07/17/2013 09:01 PM, CAI Qian wrote:
> > 
> > Please don't get me wrong. I did neither compare Linus to those child
> > abusers
> > nor Thomas to those children. I simply pointed out there is also some
> > common
> > sense need to consider.
> >
> 
> Actually, you did.
I am sorry to mislead you feeling that way, hpa.
> 
> 	-hpa
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Paolo Bonzini]

Il 16/07/2013 20:27, James Bottomley ha scritto:
> I'm perfectly happy to run linux-scsi along reasonable standards of
> civility and try to keep the debates technical, but that's far easier to
> do on a low traffic list; obviously, I realise that style of argument
> doesn't suit everyone, so it's not a standard of behaviour I'd like to
> see universally imposed.

Honestly, it is not just the low traffic, it's also that most of the
patches (90%?) are drivers that hardly anyone cares about.  There is
very little core work going on in linux-scsi, which would be a lot
harder to discuss and review (making heated tones more likely to
happen).  This is not what happens in other areas (net for example, just
to remain within drivers/).

> In fact, I've got to say that I wouldn't like
> to see *any* behaviour standard imposed ... they're all basically cover
> for power plays (or soon get abused as power plays); the only real way
> to display leadership on behaviour standards is by example not by fiat.

This I completely agree with, and you set a great example of civility.

Paolo

Re: open conflicts vs. hidden conflicts (was: [ 00/19] 3.10.1-stable review)

[Ingo Molnar]

* NeilBrown <neilb@suse.de> wrote:

> On Wed, 17 Jul 2013 20:14:40 +0200 Ingo Molnar <mingo@kernel.org> wrote:
>  
> > 1)
> > 
> > Your notion that conflicts and insults somehow hurt group cooperation 
> > is wrong. It is a scientific fact that open conflict _helps_ 
> > cooperation while hidden conflict hurts it.
> 
> I don't think anyone is seriously suggesting that open conflict is a bad 
> thing are they?

In my experience the request to "act professionally" essentially results 
in conflict avoidance and in hidden conflicts with a lot of covert 
violence.

Expecting others to suppress emotions in technically justified situations, 
to match the somewhat prudish cultural U.S. taboos of avoiding four letter 
words and gardrobe malfunction at any cost [while violence in TV and 
carrying guns around children are A-O.K.] results in that in practice.

This kills the central claim IMO, that honest, colorful, "unprofessional" 
language is somehow bad because it's hurtful.

In fact an overt flame against me is much nicer than hidden conflict 
because it's out in the open, the person emitting the flame is 
_responsible_ for the central validity of his flame.

The real choice in large scale technological development is not between 
pain and no pain, but between episodes of fast, visible pain combined with 
responsibility, or slow, creeping, long lasting pain inflicted by parties 
hidden and not really responsible and not really aware.

Why is it that some of our best, most productive developers and 
maintainers (Linus, Al Viro, Peter Zijlstra to name a few) are all known 
to be very honest and very direct in their communications, using sometimes 
colorful language if they are unhappy?

I think Steve Jobs understood that very well too.

And how is it consistent that on one hand we tell Chinese and Japanese 
kernel developers to learn to deal with the western directness of lkml 
(i.e. we declare that frank, technically correct directness and expression 
of emotions is more valuable than politeness), but then tell 
Swedish/Finnish/Russian/Dutch/German kernel developers to tone it down 
(i.e. we kind of declare the exact opposite)?

I will be the first one in the line to fight against true abuses:

 - lying
 - generating unjustified, non-technical conflict
 - showing difficulty in conflict resolution
 - outright acts of malice

A colorful Linus complaint against a top level maintainer is neither of 
these in the vast majority of cases, and it can in fact be argued to be 
technically, scientifically productive.

The suggested solution, to 'act professionally' will not avoid either of 
these abuses - in fact it makes hidden violence easier not just because it 
forces people to suppress emotions, but also because abusers cannot be 
called upon.

All in one, I just don't see the pro-PC arguments are consistent or even 
valid, I think the burden of proof is on the 'act professionally' crowd.

> I don't object to reminding everyone that conflict can be healthy and 
> valuable, but is seems to miss the main point of this discussion(*).
> 
> > 
> > 2)
> > 
> > Your notion that insults are harmful because they 'hurt' is misleading 
> > to such a level that it's almost wrong.
> > 
> > Insults do hurt of course, but that argument misses the full context: 
> > in real life the typical substitute for an avoided open conflict is 
> > not singing kumbaya around the camp fire, but _hidden_ conflict.
> 
> Open conflict != insults.

Open conflict allows for escallation of communications.

Firstly, if I messed up in a big honking way then why shouldn't Linus be 
allowed to say:

  "Argh, what the f*ck is going on here Ingo??"

Why should he hide his feelings about it and formulate in a milder way:

  "What is going on here Ingo?"

?

Maybe I'll be deluded into thinking that Linus is not really upset about 
it. The conflict is already present and there's no undoing of it. I messed 
up and Linus got upset - justifiably in the vast majority in cases. Why 
should he hide that information from me? I might not take the conflict 
seriously enough and I might repeat the mistake.

Development of large software projects is about people working together - 
hiding feelings is definitely not helpful. It takes passion to do a good 
job - and that passion has two sides to it, depending on whether good 
things or bad things happened.

Now I'm sure there's cases where Linus was wrong, although it's pretty 
rare in practice as far as I can tell, and when it happens it's not like
I couldn't defend myself. The fact that I'm still around demonstrates that 
Linus is not grudge holder.

> Certainly there is an overlap, but it is quite possible to engage in 
> open conflict without being deliberately insulting.  The appropriate 
> alternate to insults is not "hidden conflict" but rather "civil 
> bluntness".

So, the danger is the following: the moment you expect some person to act 
out of his regular, technically justified patterns of communication and 
expect him to suppress emotions you are expecting him to suppress 
conflicts in essence.

I realize that this is not what you 'want' to happen, but it is what 
_happens_ in practice.

I've seen that in several corporate environments I have worked in the 
past: hidden conflicts are abound and 'act professionally' not only 
weakens conflict resolution but is a _conduit_ for subtle, hidden 
violence.

Yes, sometimes you can get lucky in small startups, small OSS projects or 
individual kernel subsystems where everyone is really on the same page, 
where there's perfect awareness of all things technical, where there's a 
perfect match and people rhyme with each other.

The Linux kernel is not such a small startup anymore. Work reaches Linus 
in bursts of 3 months, and activity is not micro-managed. There's no 
universal awareness so larger conflicts are preprogrammed into this model, 
and I think it's better to be honest and direct early on, instead of 
letting people go in the wrong direction for extended periods of time. 

It's still a lot of fun, but it cannot possibly be a conflict-free zone 
IMO, without us growing a much larger brain.

> An extremely good rule of thumb for when you are communicating 
> emotionally is to make "I" statements.
> 
>   I don't give a #&*%$ if it fixes a bug - it introduces a @*#$$ regression
>   and that @#$*%@ is not acceptable. Ever.
> 
> is, in my mind, perfectly acceptable. [...]

While I obviously find it acceptable too, that's just a cultural 
preference that cannot be converted into some sort of generic "it is 
universally acceptable" form.

[ For example if you inject that above sentence into a Japanese corporate
  email communication and make it pass from CEO to a lower subordinate 
  then you could easily see a suicide as a result. ]

What matters is the cultural context - and sure as hell Linus has always 
communicated without suppressing his emotions too much.

As the person who started this project he's certainly entitled to setting 
the initial boundaries of the communication culture. I think it's people 
coming in that have to convince him that changing that is beneficial. What 
you cannot do is to blanket claim that 'acting professionally' is some 
magically good thing everyone knows to be beneficial.

> [...]  Saying
> 
>   You've $%^@$% done it again.
> 
> is not helpful.

Well, unless it's the second messed up pull request that day. (I managed 
to do that once in a merge window, a couple of years ago, and boy was 
Linus unhappy.)

But I really don't think Linus gratuitously insults people in an 
unprovoked way. If people keep clinging to indefensible, refuted positions 
then maybe Linus will eventually question their general mental health very 
directly, but at that point that's really just stating an inconvenient 
fact...

> http://en.wikipedia.org/wiki/I-message
> 
> (*) One of the amusing things about this whole discussion is that 
> different people seem that have very different ideas about what the core 
> issue really is.

There was never really a 'core issue' that I've seen stated clearly by the 
anti-colorful-language side, just confused suggestions resulting out of 
cultural bias or resulting out of being unaware of the many substitute 
forms of hidden violence that can thrive in politically correct email 
communications.

Thanks,

	Ingo

Re: [ 00/19] 3.10.1-stable review

[Ingo Molnar]

* CAI Qian <caiqian@redhat.com> wrote:

> > On 07/17/2013, CAI Qian wrote:
> > > 
> > > On 07/17/2013, CAI Qian wrote:
> > > > >
> > > > > Could victim be someone else in the future since it is an 
> > > > > example that people may follow?
> > > > >
> > > > > http://en.wikipedia.org/wiki/Silvio_Berlusconi_underage_prostitution_charges
> > > > >
> > > > > It called "abuse of office" or abuse of the power.
> > > > >
[...]
> > >
> > > Please don't get me wrong. I did neither compare Linus to those 
> > > child abusers nor Thomas to those children. I simply pointed out 
> > > there is also some common sense need to consider.
> > >
> > 
> > Actually, you did.
>
> I am sorry to mislead you feeling that way, hpa.

I think you are demonstrating the disutility of passive-aggressive 
communication patterns pretty nicely, making our point in essence.

Thanks,

	Ingo

Re: [ 00/19] 3.10.1-stable review

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Mon, Jul 15, 2013 at 1:41 PM, Sarah Sharp
> <sarah.a.sharp@linux.intel.com> wrote:
> >
> > Oh, FFS, I just called out on private email for "playing the victim
> > card".  I will repeat: this is not just about me, or other minorities.
> > I should not have to ask for professional behavior on the mailing lists.
> > Professional behavior should be the default.
> 

> [...]
> 
> Because if you want me to "act professional", I can tell you that I'm 
> not interested. I'm sitting in my home office wearign a bathrobe. The 
> same way I'm not going to start wearing ties, I'm *also* not going to 
> buy into the fake politeness, the lying, the office politics and 
> backstabbing, the passive aggressiveness, and the buzzwords. Because 
> THAT is what "acting professionally" results in: people resort to all 
> kinds of really nasty things because they are forced to act out their 
> normal urges in unnatural ways.

Sarah, that's a pretty potent argument by Linus, that "acting 
professionally" risks replacing a raw but honest culture with a
polished but dishonest culture - which is harmful to developing
good technology.

That's a valid concern. What's your reply to that argument?

Thanks,

	Ingo

Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Thu, 2013-07-18 at 00:01 -0400, CAI Qian wrote:
>  
> > > > So if you talk about abuse, then you need an abuser and a victim. So
> > > > your argumentation falls flat because there is no victim.
> > > Could victim be someone else in the future since it is an example that
> > > people may follow?
> > > http://en.wikipedia.org/wiki/Silvio_Berlusconi_underage_prostitution_charges
> > > It called "abuse of office" or abuse of the power.
> > 
> > Wow! You are now comparing Linus to a Prime Minister that has paid
> > underage prostitutes for sex?
> I apologize that this leads to misunderstanding. It was just happened to
> read the news that underage child does not feel like she is a victim
> either while the law still think that is an abuse. Another example, those
> BBC child abusers took ages to track down that probably because those
> children did not feel victims at that time either. 
> 
> Please don't get me wrong. I did neither compare Linus to those child abusers
> nor Thomas to those children. I simply pointed out there is also some common
> sense need to consider.

That story had nothing to do with this thread. "Abuse of power" is to
use ones power for personal gain, whether it be monetary or sexual.
Linus is not getting anything out of yelling at people (OK, it lets of
steam). Linus's yelling is a management style, nothing more.

-- Steve

Re: [ 00/19] 3.10.1-stable review

[Theodore Ts'o]

On Thu, Jul 18, 2013 at 12:01:18AM -0400, CAI Qian wrote:
> > > Could victim be someone else in the future since it is an example that
> > > people may follow?

Is Nik Wallenda an abuser because he walked across the Grand Canyon on
a tightrope without a safety net, and that's an example that other
people might follow (and fail at)?  Seriously, the argument that
someone are responsible for the actions and decisions of others is a
pretty weak one.

> > > http://en.wikipedia.org/wiki/Silvio_Berlusconi_underage_prostitution_charges
> > > It called "abuse of office" or abuse of the power.
> > 
> > Wow! You are now comparing Linus to a Prime Minister that has paid
> > underage prostitutes for sex?
> I apologize that this leads to misunderstanding. It was just happened to
> read the news that underage child does not feel like she is a victim
> either while the law still think that is an abuse.

Please show us the law which states that the language a coach might
use to his team players is "abuse".

And I think one of the big differences here is that there is a
gargantuan power differential between the Italian Prime Minister and
an underage prostitute.  The power differential between Linus and his
top subsystem maintainers?  Not so much.  Linus does not have hiring
and firing power over us, and since he works at a non-profit which
doesn't have stock options or a profit sharing agreement, he may be
making less money than compared to some of his top lieutenants.

So I'd suggest that people who are flinging around words like "abuse"
stop.  It's not helping your case, because it's not an accurate
description of what's going on.  Even if you believe that it really is
abuse, from a tactical point of view, do you think telling subsystem
maintainers (who have maintained that they do not feel personally
attack, and do not feel abused), that they are too stupid to realize
that they are really hapless victims is likely to make them listen to
your point of view?

There are much stronger arguments that can be made for more "civility".

Regards,

						- Ted

Maybe it's time to shut this thread down (Was: Re: [ 00/19] 3.10.1-stable review)

[Theodore Ts'o]

The reason why I started the kernel summit over ten years ago
was because there were certain topics that are much better discussed
in person, and that over time, if we don't have sufficient face to
face interactions, the quality of e-mail discussions can start to
become frayed.

One of the reasons is that e-mail is just not as expressive a medium
as face-to-face conversations.  As a result, when people feel that
they aren't being heard, because they aren't getting those critical
non-verbal cues, they start escalating.  They start using stronger
words, such as F*CK.  They start doing exactly what they claim to
abhor to their verbal opponents in the debate, which is describing
their fellow kernel developers using demeaning terms.  They start
using loaded, and over-reaching words, like "abuse", which ultimately
ends up hurting their own case.

I suspect this is happening because it's easy when a body feels that
their message of say, "could we please treat each other with more
respect", isn't getting heard, it's very easy and very tempting to
resort to "Linus is an AB-UUUUUUUU-SER!".

May I make the polite suggestion (and we'll see how well polite
requests get honored via e-mail), that we take this discussion
off-line, and wait to try to discuss this in person at the Kernel
Summit?

Regards,

						- Ted

Re: [ 00/19] 3.10.1-stable review

[J. Bruce Fields]

On Thu, Jul 18, 2013 at 12:39:07PM +0200, Ingo Molnar wrote:
> 
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
...
> > Because if you want me to "act professional", I can tell you that I'm 
> > not interested. I'm sitting in my home office wearign a bathrobe. The 
> > same way I'm not going to start wearing ties, I'm *also* not going to 
> > buy into the fake politeness, the lying, the office politics and 
> > backstabbing, the passive aggressiveness, and the buzzwords. Because 
> > THAT is what "acting professionally" results in: people resort to all 
> > kinds of really nasty things because they are forced to act out their 
> > normal urges in unnatural ways.
> 
> Sarah, that's a pretty potent argument by Linus, that "acting 
> professionally" risks replacing a raw but honest culture with a
> polished but dishonest culture - which is harmful to developing
> good technology.
> 
> That's a valid concern. What's your reply to that argument?

First they came for my "WTF!?!"'s, then before I knew it the only way I
could explain a simple integer-overflow problem involved
anonymously-mailed copies of K&R and subtle hint-dropping to
half-a-dozen managers!

I'm not convinced by the slippery-slope argument here.  

Speaking just for myself, yeah, I'd be happier with less yelling all
around.  I'd be even more unhappy to lose the clear, direct criticism.
(And the colorful personalities, too.  I don't see why anyone needs to
be bland.) I think that's a consistent position.

--b.

Re: [ 00/19] 3.10.1-stable review

[Sarah Sharp]

On Thu, Jul 18, 2013 at 02:42:16AM +0200, Thomas Gleixner wrote:
> If you can point me to a single instance of Linus "abusing" someone
> who is not one of his trusted persons, who really should be able to
> deal with that, or someone who did not provoke him to go into rant
> mode, then I'm all on your side.

Not that I think this link will sway you, and this thread *should*
really die down so we can discuss this at KS instead:

https://plus.google.com/+LinusTorvalds/posts/1vyfmNCYpi5

"So here's a plea: if you have anything to do with security in a distro,
and think that my kids (replace "my kids" with "sales people on the
road" if you think your main customers are businesses) need to have the
root password to access some wireless network, or to be able to print
out a paper, or to change the date-and-time settings, please just kill
yourself now. The world will be a better place."

Linus asked someone to go kill themselves.  That someone was anyone
involved in distro security, specifically OpenSuse.  I think that
qualifies as "not one of his trusted persons".  I'll leave it up to you
whether you think that statement was justified or civil.

I don't think someone in a position of power should be encouraging
developers to commit suicide, even if they did make a mistake.  The
Portland open source community has already had to deal with two
developer suicides this year (Igal Koshevoy and Matthew):

http://stumptownsyndicate.org/2013/04/09/goodbye-igal/

I personally don't want to be responsible for anyone else contemplating
suicide, even because of an obviously sarcastic "joke".  I don't joke
about suicide.  I would appreciate it if other developers refrained from
joking about it as well.

Sarah Sharp

Re: Maybe it's time to shut this thread down (Was: Re: [ 00/19] 3.10.1-stable review)

[Sarah Sharp]

On Thu, Jul 18, 2013 at 09:30:08AM -0400, Theodore Ts'o wrote:
> The reason why I started the kernel summit over ten years ago
> was because there were certain topics that are much better discussed
> in person, and that over time, if we don't have sufficient face to
> face interactions, the quality of e-mail discussions can start to
> become frayed.
> 
> One of the reasons is that e-mail is just not as expressive a medium
> as face-to-face conversations.  As a result, when people feel that
> they aren't being heard, because they aren't getting those critical
> non-verbal cues, they start escalating.  They start using stronger
> words, such as F*CK.  They start doing exactly what they claim to
> abhor to their verbal opponents in the debate, which is describing
> their fellow kernel developers using demeaning terms.  They start
> using loaded, and over-reaching words, like "abuse", which ultimately
> ends up hurting their own case.
> 
> I suspect this is happening because it's easy when a body feels that
> their message of say, "could we please treat each other with more
> respect", isn't getting heard, it's very easy and very tempting to
> resort to "Linus is an AB-UUUUUUUU-SER!".

Let's shift this discussion away from the terms "abuse" and
"professionalism" to "respect" and "civility".  I agree that calling
Linus an abuser is not conducive to moving this conversation forward.  I
agree not to use f*ck in my emails anymore, and, as Ted suggests, we'll
see how polite requests get handled.

> May I make the polite suggestion (and we'll see how well polite
> requests get honored via e-mail), that we take this discussion
> off-line, and wait to try to discuss this in person at the Kernel
> Summit?

I concur.  Let's discuss this at KS.

Sarah Sharp

Re: [ 00/19] 3.10.1-stable review

[Sarah Sharp]

On Thu, Jul 18, 2013 at 12:39:07PM +0200, Ingo Molnar wrote:
> 
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > On Mon, Jul 15, 2013 at 1:41 PM, Sarah Sharp
> > <sarah.a.sharp@linux.intel.com> wrote:
> > >
> > > Oh, FFS, I just called out on private email for "playing the victim
> > > card".  I will repeat: this is not just about me, or other minorities.
> > > I should not have to ask for professional behavior on the mailing lists.
> > > Professional behavior should be the default.
> > 
> 
> > [...]
> > 
> > Because if you want me to "act professional", I can tell you that I'm 
> > not interested. I'm sitting in my home office wearign a bathrobe. The 
> > same way I'm not going to start wearing ties, I'm *also* not going to 
> > buy into the fake politeness, the lying, the office politics and 
> > backstabbing, the passive aggressiveness, and the buzzwords. Because 
> > THAT is what "acting professionally" results in: people resort to all 
> > kinds of really nasty things because they are forced to act out their 
> > normal urges in unnatural ways.
> 
> Sarah, that's a pretty potent argument by Linus, that "acting 
> professionally" risks replacing a raw but honest culture with a
> polished but dishonest culture - which is harmful to developing
> good technology.
> 
> That's a valid concern. What's your reply to that argument?

I don't feel the need to comment, because I feel it's a straw man
argument.  I feel that way because I disagree with the definition of
professionalism that people have been pushing.

To me, being "professional" means treating each other with respect.  I
can show emotion, express displeasure, be direct, and still show respect
for my fellow developers.

For example, I find the following statement to be both direct and
respectful, because it's criticizing code, not the person:

"This code is SHIT!  It adds new warnings and it's marked for stable
when it's clearly *crap code* that's not a bug fix.  I'm going to revert
this merge, and I expect a fix from you IMMEDIATELY."

The following statement is not respectful, because it targets the
person:

"Seriously, Maintainer.  Why are you pushing this kind of *crap* code to
me again?  Why the hell did you mark it for stable when it's clearly
not a bug fix?  Did you even try to f*cking compile this?"

I would appreciate it if people would replace the word "professional"
with "respectful" in this thread.  It means something different to me
than other people, and respect is much closer to what I'm looking for.

I would appreciate it if kernel developers would show respect for each
other, while focusing on criticizing code.  As Rusty said, be gentle
with people.  You've called their baby ugly.

Sarah Sharp

Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Thu, 2013-07-18 at 09:07 -0700, Sarah Sharp wrote:

> The following statement is not respectful, because it targets the
> person:
> 
> "Seriously, Maintainer.  Why are you pushing this kind of *crap* code to
> me again?  Why the hell did you mark it for stable when it's clearly
> not a bug fix?  Did you even try to f*cking compile this?"

No it does not target the person at all. It targets what the person
*did*.

"Why are you *pushing* this ..."
"Why the hell *did* you mark it..."
"*Did* you even try to ..."

See, it's all about the fact that the person did something stupid, and
they are being called out on it. It is not any more of an attack on the
person as the one attacking the code.

But we can discuss this in more detail at KS.

-- Steve

Re: [ 00/19] 3.10.1-stable review

[Felipe Contreras]

On Thu, Jul 18, 2013 at 11:07 AM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:

> To me, being "professional" means treating each other with respect.

Respect is earned, not automatic, and can be lost. A common mistake in
our modern society is to think that everyone deserves respect; they
don't.

We should tolerate each other, not respect each other.

-- 
Felipe Contreras

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Paul E. McKenney]

On Thu, Jul 18, 2013 at 12:01:05PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2013-07-17 at 10:14 +0400, James Bottomley wrote:
> > > OK, I am stupid enough to take a stab at this...
> > > 
> > > 1.    Does the Linux kernel community's health depend on the occasional
> > >       rant?  [My guess is that we simply have no way of knowing.
> > >       That said, I would be interested in hearing specific examples
> > >       of open-source communities that are as doing as well as is the
> > >       Linux community and that live within stricter social mores.
> > >       Cue arguments about exactly what "doing well" means...]
> 
> My little personal opinion (that nobody probably cares about :-) is that
> the occasional Linus rant is a good thing. It keeps people like me in
> check :-)
> 
> More seriously, the rant when I screw up is generally deserved, and the
> "idea" of the possible rant (I prefer not using threat) is actually a
> strong motivator to get things right.
> 
> Ie. It's a *very good* barrier against maintainers sliding into
> sloppyness. Really, it works. At least with me.
> 
> It's easy to take things a bit too much for granted, especially when you
> maintain your own little corner of the world.

Agreed!  Though I must confess that I have shifted from being mostly
worried about people yelling at me to being mostly worried about my own
code yelling at me.  Either way, I do find that being worried about some
consequence or another does help me get a better result.

							Thanx, Paul

Re: [ATTEND] How to act on LKML

[Dave Chiluk]

On 07/15/2013 05:38 PM, Linus Torvalds wrote:
> A small panel discussion with a few people (fiveish?) that have very
> different viewpoints, along with baskets of rotten fruit set out on
> the tables?

As I think the purpose of this discussion was to improve linux by
attracting and growing new talent, may I suggest that you include a
greenhorn submitter on such a panel.

Dave.

mistakes in code vs. maintainer flow mistakes (was: [ 00/19] 3.10.1-stable review)

[Ingo Molnar]

* Sarah Sharp <sarah.a.sharp@linux.intel.com> wrote:

> On Thu, Jul 18, 2013 at 12:39:07PM +0200, Ingo Molnar wrote:
> > 
> > * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > 
> > > On Mon, Jul 15, 2013 at 1:41 PM, Sarah Sharp
> > > <sarah.a.sharp@linux.intel.com> wrote:
> > > >
> > > > Oh, FFS, I just called out on private email for "playing the victim
> > > > card".  I will repeat: this is not just about me, or other minorities.
> > > > I should not have to ask for professional behavior on the mailing lists.
> > > > Professional behavior should be the default.
> > > 
> > 
> > > [...]
> > > 
> > > Because if you want me to "act professional", I can tell you that I'm 
> > > not interested. I'm sitting in my home office wearign a bathrobe. The 
> > > same way I'm not going to start wearing ties, I'm *also* not going to 
> > > buy into the fake politeness, the lying, the office politics and 
> > > backstabbing, the passive aggressiveness, and the buzzwords. Because 
> > > THAT is what "acting professionally" results in: people resort to all 
> > > kinds of really nasty things because they are forced to act out their 
> > > normal urges in unnatural ways.
> > 
> > Sarah, that's a pretty potent argument by Linus, that "acting 
> > professionally" risks replacing a raw but honest culture with a
> > polished but dishonest culture - which is harmful to developing
> > good technology.
> > 
> > That's a valid concern. What's your reply to that argument?
> 
> I don't feel the need to comment, because I feel it's a straw man 
> argument.  I feel that way because I disagree with the definition of 
> professionalism that people have been pushing.

I hope you won't take this as a sign of disrespect, but it's hard to keep 
up with your somewhat fluid opinion about what exactly you find 
objectionable :-/

Early in the thread you claimed it's about politeness:

> Sarah Sharp <sarah.a.sharp@linux.intel.com> wrote:
>
> [...] I've seen you be polite, and explain to clueless maintainers why 
> there's no way you can revert their merge that caused regressions, and 
> ask them to fit it without resorting to tearing them down emotionally:
>
>   http://marc.info/?l=linux-kernel&m=136130347127908&w=2
>
> You just don't want to take the time to be polite to everyone.  Don't 
> give me the "I'm not polite" card.  Go write some documentation about 
> what's acceptable for stable.

But now you claim something else, it's OK to be impolite, it's just not OK 
to do XYZ ... and it's unclear to me what you mean under XYZ exactly. 
Right now you say XYZ is "disrespect":

> To me, being "professional" means treating each other with respect.  I 
> can show emotion, express displeasure, be direct, and still show respect 
> for my fellow developers.

But what is there to respect about a colossal maintainer f*ck-up, which is 
inextricably tied to the person? Do you really think if Linus replaced 
this:

 "  Ingo, this is just so mind-boggingly STUPID, how did you even f*cking 
    THINK of doing something like that??  "

with a respectful and still truthful statement:

 "
   Ingo, I fully respect you [*] but this is just mind-boggingly
   STUPID, how did you even f*cking THINK of doing something like that??

   [*] Unless you keep doing such sh*t too many times, of course. Then I
       won't respect you anymore and will ignore your patches. You are not 
       my friend, you are a top level maintainer in a meritocracy. There's 
       a way both up and down.
 "

then I would not feel just as bad about it all?

> For example, I find the following statement to be both direct and 
> respectful, because it's criticizing code, not the person:
> 
> "This code is SHIT!  It adds new warnings and it's marked for stable 
> when it's clearly *crap code* that's not a bug fix.  I'm going to revert 
> this merge, and I expect a fix from you IMMEDIATELY."
> 
> The following statement is not respectful, because it targets the 
> person:
> 
> "Seriously, Maintainer.  Why are you pushing this kind of *crap* code to 
> me again?  Why the hell did you mark it for stable when it's clearly not 
> a bug fix?  Did you even try to f*cking compile this?"

Well, but often it's the action of the maintainer that what was wrong, not 
the patch primarily.

Mistakes in patches and code happen all the time. Linus rarely if ever 
flamed me for _that_ - sh*t happens.

What he flames me for, and what you (with all due respect) still don't 
seem to understand, are _META_ mistakes. Top level maintainer level 
mistakes. Bad patterns of maintainer behavior that really should not occur 
because they could affect many patches in the future, such as:

 - trying to argue regressions away - i.e. not 'shutting up' in time, 
   being a meta hindrance to problem resolution

 - doing a sloppy Git flow, repeatedly

 - not testing adequately, especially when the pull request occurs at a 
   critical time (such as a couple of hours before -rc1)

 - [ and many other meta mistakes ]

None of those arguments are about code and still I fully expect Linus to 
pin those on me if he notices a meta bug in my behavior and finds it 
dangerous.

> I would appreciate it if people would replace the word "professional" 
> with "respectful" in this thread.  It means something different to me 
> than other people, and respect is much closer to what I'm looking for.
> 
> I would appreciate it if kernel developers would show respect for each 
> other, while focusing on criticizing code.  As Rusty said, be gentle 
> with people.  You've called their baby ugly.

But Linus doesn't really criticise mistakes in code primarily when he 
flames top level maintainers!

Read the very examples you dug out of the lkml archives, the Linus "worst 
of" list. Sure, some bad code is almost always part of a specific 
incident, but primarily he criticises the maintainer flow, and that is 
fundamentally tied to the _person_.

_That_ is why it might look to you as if the person was attacked, because 
indeed the actions of the top level maintainer were wrong and are 
criticised.

... and now you want to 'shut down' the discussion. With all due respect, 
you started it, you have put out various heavy accusations here and 
elsewhere, so you might as well take responsibility for it and let the 
discussion be brought to a conclusion, wherever that may take us, compared 
to your initial view?

Thanks,

	Ingo

Re: mistakes in code vs. maintainer flow mistakes (was: [ 00/19] 3.10.1-stable review)

[Ingo Molnar]

* Ingo Molnar <mingo@kernel.org> wrote:

> [...]
> 
> Mistakes in patches and code happen all the time. Linus rarely if ever 
> flamed me for _that_ - sh*t happens.
> 
> What he flames me for, and what you (with all due respect) still don't 
> seem to understand, are _META_ mistakes. Top level maintainer level 
> mistakes. Bad patterns of maintainer behavior that really should not 
> occur because they could affect many patches in the future, such as:
> 
>  - trying to argue regressions away - i.e. not 'shutting up' in time, 
>    being a meta hindrance to problem resolution
> 
>  - doing a sloppy Git flow, repeatedly
> 
>  - not testing adequately, especially when the pull request occurs at a 
>    critical time (such as a couple of hours before -rc1)
> 
>  - [ and many other meta mistakes ]
> 
> None of those arguments are about code and still I fully expect Linus to 
> pin those on me if he notices a meta bug in my behavior and finds it 
> dangerous.

And note that whenever I or a fellow -tip maintainer got such an unhappy 
complaint from Linus in the past couple of years our response wasn't just 
to fix some broken code.

Our response was to fix broken top level maintainer behavior, by applying 
'meta fixes':

  - changing our Git workflow

  - adding more scripting to catch bad commits

  - changing our flow of sending pull requests, adding fail-safes

  - trying to think more neutrally about bug reports to avoid punishing 
    the messenger and to avoid arguing regressions away

  - hardening our review process

  - making sure at least one -tip maintainer watches lkml for bugreports

  - tightening our controls to avoid missed patches

  - thinking about the timing of pull requests

  - etc., etc.

(And there's an even larger body of 'meta fixes' we applied without being 
prodded by Linus.)

On the outside such incidents look like as if Linus flamed 'the person' in 
a disrespectful way.

What Linus _really_ flamed us for in 95% of the cases was the meta 
process, the 'meta code' of Linux, which is not actual source code but 
mostly a social construct, informal patterns of human behavior - and those 
are inextricably embedded in the person.

And because the 'meta fixes' too are often of social nature, what you see 
when reading lkml is just a unidirectional stream of complaints from 
Linus. You typically don't see patch notifications of changed behavior. 
Nor do you see top level maintainers 'speaking up against Linus' very 
often: these are bugreports from Linus and we simply fix them, there's not 
much to speak up against.

Linus is very laissez-faire about maintainence, so whenever he _does_ 
erupt at us (at a clip of ~10,000 commits per cycle that do go in without 
any complaint from Linus) it's justified in a large percentage of cases.

So despite the outside appearance this is not top level Linux maintainers 
being oppressed by Linus or suffering from some sort of Stockholm Syndrome
:-)

We are just as stubborn as Linus and do speak up against Linus when needed 
- it just rarely is necessary - in great part because Linus flames in 
public and takes care he is upset for a good reason so he does not have to 
walk back on his flame. Public embarrassment cuts both ways.

When Linus's complaint is unjustified top level maintainers _do_ speak up 
- see Thomas Gleixner's recent example, which resulted in Linus 
apologizing. (It's a rare occurance and we've archived all the emails for 
the history books.)

Thanks,

	Ingo

Re: [ 00/19] 3.10.1-stable review

[Ingo Molnar]

* Sarah Sharp <sarah.a.sharp@linux.intel.com> wrote:

> On Thu, Jul 18, 2013 at 02:42:16AM +0200, Thomas Gleixner wrote:
> > If you can point me to a single instance of Linus "abusing" someone
> > who is not one of his trusted persons, who really should be able to
> > deal with that, or someone who did not provoke him to go into rant
> > mode, then I'm all on your side.
> 
> Not that I think this link will sway you, and this thread *should*
> really die down so we can discuss this at KS instead:
> 
> https://plus.google.com/+LinusTorvalds/posts/1vyfmNCYpi5
> 
> "So here's a plea: if you have anything to do with security in a distro,
> and think that my kids (replace "my kids" with "sales people on the
> road" if you think your main customers are businesses) need to have the
> root password to access some wireless network, or to be able to print
> out a paper, or to change the date-and-time settings, please just kill
> yourself now. The world will be a better place."
> 
> Linus asked someone to go kill themselves. [...]

No, he did not.

He, as he declared it in the first stentences of his post, was venting and 
cursing:

   Venting.

   I don't think I can talk about "security" people without cursing, so
   you might want to avert your eyes now.

I'm, as the author of several security patches, partly a distro "security 
person" too, and I was not offended, I took away the message from Linus:

don't "fix" perceived security threats by cumbersome security measures, 
because users will address that by creating even larger security threats:

   http://www.merseyworld.com/precinct/Apr99/prec8.html

Thanks,

	Ingo

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Ingo Molnar]

* Steven Rostedt <rostedt@goodmis.org> wrote:

> On Wed, 2013-07-17 at 11:51 -0700, Sarah Sharp wrote:
> 
> > > I have to ask. How much verbal abuse have you received in LKML? And I
> > > don't mean in this thread.
> > 
> > I assume you also want me to exclude the verbal abuse and personal
> > threats I've received via email and my blog because of this thread.
> > But, just for reference, I'll post them here as well.
> 
> That's the nastiness of the Internet, a different topic than LKML
> development. And I don't consider this thread really a LKML thread, as
> it's about social behavior and nothing about the Linux kernel itself.
> 
> > 
> > Here's a gem from a senior software developer at Nvidia:
> > https://picasaweb.google.com/116960357493251979546/Trolls#5901298464591248626
> > 
> > And another email from a software developer in Portland, where I live:
> > https://picasaweb.google.com/116960357493251979546/Trolls#5901288095984358098
> 
> Both are cowardly trolls that didn't post publicly.
> 
> > 
> > On my blog, here's some choice comments, mostly asking me to quit kernel
> > development, along with more than a few misogynist comments:
> > 
> > "You volunteered to help out on the Linux journey. He never volunteered
> > to care for your feelings, nor did anyone else. It???s an opt-in community
> > and you can always opt out at any time. Caveat emptor."
> > 
> > "You???re no one compared to Linus. Start being Alan Cox or Theodore T???so
> > first to criticize him for his behaviour."
> > 
> > "Drama Queen"
> > 
> > "The LKML is not a place for easily offended girls to be. Get over
> > yourself."
> > 
> > "shit, just what we need ??? a bitch running around crying about how hurt
> > her feelings are."
> > 
> > "Oy vey you poor goyi???girl. You need to teach these sexist boys that
> > being racist is wrong. Think of the wonderful things that womyn have
> > done in the IT field. Clearly Linus is a rape apologist who fosters
> > negative views of minorities."
> > 
> > "This is why women are viewed as pathetic jokes, especially in the tech
> > world ??? because you???re weak and ineffectual, insufferable pansies who
> > expect the world to cater and accommodate your thin skin and easily
> > offended hyper-sensibilities. Grow the fuck up bitch. It???s real cute how
> > you???ve tried to paint yourself as some gallant Joan of Arc, crusading
> > against ???muh bigotry??? and ???muh intolerance.??? You???re a feminist joke, one
> > in a very long line."
> 
> Again, this is the Internet social media, which is not an environment 
> for productivity, but a cesspool of filth. Off topic to what I asked.
> 
> > Speaking out about this has made the crazies come out of the woodwork.
> 
> And what did you expect? The Internet if filled with assholes.

It's worse than that: being an asshole appears to also be correlated with 
the likelihood of speaking up on forums! So assholes are overrepresented, 
especially on forums that are semi-anonymous.

Sarah, you should see some of the hateful comments I got over past 
scheduler maintenance decisions... [Or rather, you should not.]

When being involved in polarizing discussions, especially if you yourself 
frame it as polarizing, you should expect to receive a wide spectrum of 
opinion and outright trolling.

The hateful, despicable, abhorrent trolling you cited should not be 
projected over to your opponent in the discussion, unless your opponent 
voices it as well ...

Thanks,

	Ingo

Re: [ 00/19] 3.10.1-stable review

[Ingo Molnar]

* Sarah Sharp <sarah.a.sharp@linux.intel.com> wrote:

> On Tue, Jul 16, 2013 at 03:12:45PM -0700, Linus Torvalds wrote:
> > I react very strongly when somebody argues against fixing regressions.
> > Let's just say that there's too many years of baggage that I carry
> > around on that issue..
> > 
> > So that is definitely one of the things that make me go ballistic.
> > Buggy code isn't actually one of them. Bugs happen. Even really stupid
> > bugs happen, and happen to good people. They had a bad day, or it was
> > just a brainfart.  Not that I will be _polite_ about bad code, mind
> > you, and there might be some bad words in there, but it doesn't make
> > me blow up.
> > 
> > Being cavalier about known regressions is definitely the primary
> > trigger. I suspect there are others, but I can't seem to recall any
> > other particular hot-button issues right now. Maybe Sarah can post a
> > few more pointers..
> 
> Hmm... The only thing I can think of off the top of my head is that you 
> tend to hate it when someone puts the needs of their particular 
> architecture or distro at a higher priority than the needs of the kernel 
> community.  If they start to push crap code late in the merge window to 
> further their personal goals, you tend to blow up at them.  See the 
> 'deep throat' comment on the PE binary signing thread, for instance.
> 
> The timing of when incidents happen also seems to effect whether you get 
> triggered.  I suspect most of the incidents of you "blowing up" at 
> people happen during the merge window.

Of course timing matters:

 - there are times when a bad pull request can have worse effects, such as 
   shortly before -rc1 or shortly before -final - when many people will be 
   exposed to a new kernel for the first time.

 - timing can also sometimes show a certain level of dishonesty on the 
   developer's side: trying to slip in a bad tree near the end of the 
   merge window, before people can complain it ...

 - there are times when Linus naturally more vulnerable to not having 
   enough time to think things through: such as when he is pulling a dozen 
   trees per day, during the merge window.

Dishonesty, bad timing, running a bad Git flow and making irreversible ABI 
mistakes [of which refusing to fix app regressions is one sort] are all 
hot button issues for Linus, and it's a pretty natural list I think: 
because they are the least actionable, most persistent and thus riskiest 
"meta" problems possible in a kernel project.

Some of Linus's "worst" flames had two or more of these hot button issues 
mixed together. Sometimes a maintainer can get away with a mistake (most 
likely Linus does not notice the mistake) but in general it's all pretty 
consistent.

All in one, with all due respect, I don't think your complaints voiced so 
far against Linus have much merit :-/ I think you'll experience it first 
hand once you become a top level maintainer.

Having said that, I do share your concern that women are more offput by 
the widespread 'manly' talk on lkml: LKML is filled with testosterone. I 
think your solution to create a separate culture is a good one - and 
eventually the two cultures will counter-balance each other in a good way 
and will maybe merge. I cannot think of a better solution either, and I 
fully support your efforts: it's one of the big unsolved problems of Linux 
kernel development.

Thanks,

	Ingo

Re: [ 00/19] 3.10.1-stable review

[Ingo Molnar]

* Rob Landley <rob@landley.net> wrote:

> On 07/15/2013 10:52:48 AM, Sarah Sharp wrote:
> >On Fri, 12 Jul 2013 18:17:08 +0200, Ingo Molnar <mingo@kernel.org>
> >wrote:
> >> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >Let's discuss this at Kernel Summit where we can at least yell at each
> >other in person.  Yeah, just try yelling at me about this.  I'll roar
> >right back, louder, for all the people who lose their voice when they
> >get yelled at by top maintainers.  I won't be the nice girl anymore.
> 
> Not _all_ of us lose our voice when yelled at by Linus's lieutenants. 
> Some of us just post updates to the same darn patch series for 5 years 
> (yes really; my perl removal series started in 2008 and was applied 
> earlier this year), on the theory it's useful to the people actually 
> applying it to their own trees (at one point, gentoo), and that someday 
> the stars might be right and cthulu will arise from the deep and accept 
> the patch series into his tree. (Or in my case, Andrew Morton.)

I think part of the root cause was that kbuild maintainership changed 
several times over the years and nobody really felt strongly enough about 
the Perl removal series.

Despite best efforts there will always be long-lived Linux forks: the 
-rt/PREEMPT_RT kernel is meanwhile nearly a decade old now... :-/

Thanks,

	Ingo

Re: [ATTEND] How to act on LKML

[Ingo Molnar]

* Willy Tarreau <w@1wt.eu> wrote:

> On Wed, Jul 17, 2013 at 07:40:43AM -0700, Sarah Sharp wrote:
>
> > Go look at Dreamwidth, the open source Livejournal fork.  It has a 
> > good code of conduct, so developers are civil to each other.  They 
> > encourage all patch submissions, and take the time to work with people 
> > who don't understand their community rules.
> > 
> > The result: 75% of their developers are women.  If you give a flying 
> > fuck about diversity, and want to attract women to your open source 
> > project, your developers need to be civil, and not verbally abuse each 
> > other.
> 
> But this has nothing to do with a project's success or quality, gender 
> is not related. Are you suggesting that with more women the Linux kernel 
> would be a more successful project ? If so I think you're a bit biased. 
> In my opinion, only its good people make it a good project, whatever 
> their gender.

I don't necessarily agree with everything that Sarah has stated, but I 
think we can declare it with scientific certainty that utilizing the other 
50% of creative brainpower that humanity has available can only improve 
the Linux kernel, and drastically so.

( The "how" is the 1 trillion dollars question, and I'm glad Sarah is
  working on that problem. )

Thanks,

	Ingo

Re: [ATTEND] How to act on LKML

[Ingo Molnar]

* Felipe Contreras <felipe.contreras@gmail.com> wrote:

> [...]
> 
> Anyway, through the discussion it has been established that swearing is 
> rare, most of often directed to the code, and on exceptional occasions 
> directed to people, when they *deserve* it. And you seem to be implying 
> that women can't tolerate that, so a change needs to be made in order to 
> attract more women to the project. Is that correct?

While I don't talk for Sarah, the way you have put it is broadly correct 
(although your formulation is adversarial and leading): most communities 
dominated by women are hugely offputting to males and communities 
dominated by males are hugely offputting to women.

Open communities dominated by one gender (males in most cases) that want 
to essentially double their creative brain capacity by attracting the 
other gender are well advised to try to figure out a solution to that 
problem.

> Personally I don't believe that. Essentially every other open source 
> project out there, except the Linux kernel, has some kind code of 
> conduct, whether it's implicit or explicit, and yet they don't have many 
> developer women either. But fine, let's suppose what you say it's true.

Code of conduct is unfortunately not enough - there's many conscious and 
subconscious dimensions to a community that make it offputting to one 
gender or the other and once a community becomes a mono-culture by one 
gender (due to historic gender bias or due to sheer luck) it's (very) hard 
to change it.

> As Linus already pointed out, not everybody has to work with everybody.

That's not the point though, the point is to potentially roughly double 
the creative brain capacity of the Linux kernel project.

Even if you don't care about gender fairness, that kind of bona fide 
benefit to the project is worth a try or two I think ...

Thanks,

	Ingo

Re: mistakes in code vs. maintainer flow mistakes (was: [ 00/19] 3.10.1-stable review)

[Kurt H Maier]

On Fri, Jul 19, 2013 at 11:22:56AM +0200, Ingo Molnar wrote:
> 
> ... and now you want to 'shut down' the discussion. With all due respect, 
> you started it, you have put out various heavy accusations here and 
> elsewhere, so you might as well take responsibility for it and let the 
> discussion be brought to a conclusion, wherever that may take us, compared 
> to your initial view?
> 

This wasn't about having a discussion, it was about "taking a stand,"
and since the reaction to the stand wasn't unanimously supportive, it's
easier to take it inside the wire, out of public view, before backing
down.

khm

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[H. Peter Anvin]

On 07/18/2013 11:03 PM, Paul E. McKenney wrote:
>>
>> Ie. It's a *very good* barrier against maintainers sliding into
>> sloppyness. Really, it works. At least with me.
>>
>> It's easy to take things a bit too much for granted, especially when you
>> maintain your own little corner of the world.
> 
> Agreed!  Though I must confess that I have shifted from being mostly
> worried about people yelling at me to being mostly worried about my own
> code yelling at me.  Either way, I do find that being worried about some
> consequence or another does help me get a better result.
> 

Yes.  Linus' little rant from last weekend has had me and the other tip
maintainers look at process changes and new tooling, which we probably
should have done a while ago... but it just got way too buried on the
list of priorities.

	-hpa

Re: [ATTEND] How to act on LKML

[Felipe Contreras]

On Fri, Jul 19, 2013 at 7:08 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Felipe Contreras <felipe.contreras@gmail.com> wrote:

>> As Linus already pointed out, not everybody has to work with everybody.
>
> That's not the point though, the point is to potentially roughly double
> the creative brain capacity of the Linux kernel project.

Unfortunately that's impossible; we all know there aren't as many
women programmers as there are men. So there's absolutely *nothing*
the Linux kernel can do to double the creative brain capacity of the
Linux kernel project (at least with respect to women).

At best that is a societal/academic/professional issue, not a Linux issue.

> Even if you don't care about gender fairness, that kind of bona fide
> benefit to the project is worth a try or two I think ...

I think the Linux kernel is perfectly gender-fair, in fact, you don't
even need to state you gender; you would be treated the same either
way.

But you are avoiding the question as well; do you think there's
something fundamentally different about the female brain that makes
them more susceptible to personal attacks? If yes, where is the
scientific evidence? If there's no evidence, then it's merely an
opinion that is not shared by others (e.g. me), and if no, then
whatever the men can take, the women can take as well, so nothing
needs to change.

-- 
Felipe Contreras

Re: [ATTEND] How to act on LKML

[Steven Rostedt]

On Fri, 2013-07-19 at 13:42 -0500, Felipe Contreras wrote:

> But you are avoiding the question as well; do you think there's
> something fundamentally different about the female brain that makes
> them more susceptible to personal attacks? If yes, where is the
> scientific evidence? If there's no evidence, then it's merely an
> opinion that is not shared by others (e.g. me), and if no, then
> whatever the men can take, the women can take as well, so nothing
> needs to change.

I don't know bout susceptible to personal attacks, but I have two
teenage daughters and I can't figure them out yet. I'll say something
that I think might get them upset and they are fine with it. Then I'll
say something, where I see no harm, and suddenly I'm the most evil
person in the world and they go all emotional on me.

Women are too complex for me to figure out. Perhaps men are just too
simple minded (my wife keeps telling me that). Or perhaps it's just
me ;-)

-- Steve

Re: mistakes in code vs. maintainer flow mistakes (was: [ 00/19] 3.10.1-stable review)

[Sarah Sharp]

On Fri, Jul 19, 2013 at 11:22:56AM +0200, Ingo Molnar wrote:
> 
> * Sarah Sharp <sarah.a.sharp@linux.intel.com> wrote:
> 
> > On Thu, Jul 18, 2013 at 12:39:07PM +0200, Ingo Molnar wrote:
> > > 
> > > * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > > 
> > > > On Mon, Jul 15, 2013 at 1:41 PM, Sarah Sharp
> > > > <sarah.a.sharp@linux.intel.com> wrote:
> > > > >
> > > > > Oh, FFS, I just called out on private email for "playing the victim
> > > > > card".  I will repeat: this is not just about me, or other minorities.
> > > > > I should not have to ask for professional behavior on the mailing lists.
> > > > > Professional behavior should be the default.
> > > > 
> > > 
> > > > [...]
> > > > 
> > > > Because if you want me to "act professional", I can tell you that I'm 
> > > > not interested. I'm sitting in my home office wearign a bathrobe. The 
> > > > same way I'm not going to start wearing ties, I'm *also* not going to 
> > > > buy into the fake politeness, the lying, the office politics and 
> > > > backstabbing, the passive aggressiveness, and the buzzwords. Because 
> > > > THAT is what "acting professionally" results in: people resort to all 
> > > > kinds of really nasty things because they are forced to act out their 
> > > > normal urges in unnatural ways.
> > > 
> > > Sarah, that's a pretty potent argument by Linus, that "acting 
> > > professionally" risks replacing a raw but honest culture with a
> > > polished but dishonest culture - which is harmful to developing
> > > good technology.
> > > 
> > > That's a valid concern. What's your reply to that argument?
> > 
> > I don't feel the need to comment, because I feel it's a straw man 
> > argument.  I feel that way because I disagree with the definition of 
> > professionalism that people have been pushing.
> 
> I hope you won't take this as a sign of disrespect, but it's hard to keep 
> up with your somewhat fluid opinion about what exactly you find 
> objectionable :-/

The good news is you're confused because I've been influenced by some of
the arguments people have made on this thread.  As a result, my
viewpoints may have changed subtly, and I've given up arguing other
points because it's clear people are clinging to certain behaviors, and
I'm not going to change their mind about them.

I apologize for causing confusion, and I will attempt to restate my
current opinion.

There are essential three types of "attacks" that are being discussed on
this thread:

1. Personal attacks
2. Attacks against people's behaviors
3. Attacks against code

People, in general, agree that #3 (attacks on code) is fine.  Most kernel
developers will attempt to be civil when giving code review, and I don't
see an issue with telling someone politely that their code needs to be
fixed.

Many developers have stated they feel it's OK to flame someone that
continues to push bad code over and over without taking the maintainer's
feedback into account.  My issue is that maintainers should try simply
saying, "No, this is bad code, and I WILL NOT take it" before flaming the
individual.  Anything else is simply the maintainer venting their
frustration at the submitter in a public forum.  This could be constituted
as a personal attack, depending on what language is used in the flame
email.

So, #3 (attacks against code) may be appropriate community behavior, but
it's up to the maintainer to decide what language is appropriate, and how
many times they want to be nice before they start to flame someone.

I believe that most kernel developers agree that #1 (personal attacks)
aren't appropriate, but they disagree about what constitutes a personal
attack.  Several kernel developers have expressed that they think #2
(attacks against people's behavior) is socially acceptable, when it comes
infrequently from Linus.

I think the key here is "from Linus".  Research has shown that verbal
abuse and bullying rarely comes from subordinates criticizing people in
power.  The book "No Assholes Rule" cites research that shows only 1% of
subordinates bully their superiors.  That's because people (like me) who
are not in a position of power face intense push back from the community
and personal harassment from jerks on the internet when they question or
cuss at someone in a position of power.  But, it's perfectly socially
acceptable for Linus to cuss out a person below him in the kernel tree
hierarchy.

Do you see the power dynamics issue here?  No one in the community is
willing to call out Linus when he tells Mauro to SHUT THE FUCK UP, which
is a personal attack.  Several people in the community have jumped at
criticizing my use of the word fuck in sentences that are not personal
attacks.  I.e. "If you give a flying fuck about diversity, the kernel
community members should avoid verbal abuse."

There's a severe double standard here.  Let's talk about this elephant in
the room, rather than sweeping it under the rug.


There's a very very fine line between personal attacks and attacks
pointing out people's bad behavior.  In my opinion, developers need to
be very respectful when giving negative feedback on a person's behavior,
in order to make sure the attack isn't perceived as a personal attack.

"Respect" means different things to different people.  Here's a list of
potentially disrespectful behaviors:

 * cussing
 * belittling statements
 * demeaning sarcasm
 * telling someone to SHUT THE FUCK UP
 * overuse of ALL CAPS to prove a point
 * encouraging suicide (telling someone to go kill themselves)
 * hysteria (inappropriate over-reaction to a bad situation)
 * name calling (calling someone stupid, a moron, etc)
 * insulting someone's technical skills
 * making people feel inferior
 * rewriting someone's code and submitting it without credit to them
 * ...and not apologizing for these behaviors when someone proves you
   are wrong about the situation, or over-reacting.

When these behaviors are combined with giving negative feedback on
someone's behavior, some developers may perceive the email as a personal
attack.  That's why I advocate minimizing these behaviors in
communications between Linus and his lieutenants about their bad
behavior as maintainers.


> Early in the thread you claimed it's about politeness:
> 
> > Sarah Sharp <sarah.a.sharp@linux.intel.com> wrote:
> >
> > [...] I've seen you be polite, and explain to clueless maintainers why 
> > there's no way you can revert their merge that caused regressions, and 
> > ask them to fit it without resorting to tearing them down emotionally:
> >
> >   http://marc.info/?l=linux-kernel&m=136130347127908&w=2
> >
> > You just don't want to take the time to be polite to everyone.  Don't 
> > give me the "I'm not polite" card.  Go write some documentation about 
> > what's acceptable for stable.
> 
> But now you claim something else, it's OK to be impolite, it's just not OK 
> to do XYZ ... and it's unclear to me what you mean under XYZ exactly. 

I changed my stated viewpoint, because I'm clearly not going to get
anyone to change their mind about cussing on the mailing list, or
attempting to be civil to people who send crap code.  I can't change any
hearts or minds there, so my focus in the most recent threads has been
on whether we can agree that personal attacks and attacking a person's
behavior is not acceptable.

> Right now you say XYZ is "disrespect":
> 
> > To me, being "professional" means treating each other with respect.  I 
> > can show emotion, express displeasure, be direct, and still show respect 
> > for my fellow developers.
> 
> But what is there to respect about a colossal maintainer f*ck-up, which is 
> inextricably tied to the person? Do you really think if Linus replaced 
> this:
> 
>  "  Ingo, this is just so mind-boggingly STUPID, how did you even f*cking 
>     THINK of doing something like that??  "

Let's see, this includes:
 * name calling
 * insults about your intelligence
 * ALL CAPS

> 
> with a respectful and still truthful statement:
> 
>  "
>    Ingo, I fully respect you [*] but this is just mind-boggingly
>    STUPID, how did you even f*cking THINK of doing something like that??
> 
>    [*] Unless you keep doing such sh*t too many times, of course. Then I
>        won't respect you anymore and will ignore your patches. You are not 
>        my friend, you are a top level maintainer in a meritocracy. There's 
>        a way both up and down.
>  "
> 
> then I would not feel just as bad about it all?

If Linus feels that he needs to use name calling and insults in order to
get his point heard, I would appreciate if he prefaced his statements
with "I respect you, but seriously..."

I think the issue here is that Linus' lieutenants *know* Linus trusts
and respects him, and most of them don't need that prefix to his
emails.  That leads people to look at Linus' email to Mauro, and say
things like, "Linus is just expressing his disappointment that his
maintainer violated his trust by refusing to fix a regression."

https://lkml.org/lkml/2012/12/23/75

The problem is, without the prefix of "I respect you" or "Your pull
requests are normally flawless", outsiders to our community don't
understand the context.  They don't see this as an "I trust you, but you
fucked up" email.  They see this as a verbally abusive message from
Linus.

Perhaps what might help here is a kernel organizational chart.  A graph
of who sends pull requests to Linus, and their subsystem maintainers.
For example, in the USB "branch" there would be:

				Linus Torvalds
			(Linux kernel release engineer)
					|
					|
				Greg Kroah-Hartman
				      (USB)
					|
					|
			-------------------------------------------------
			|		|		|		|
			|		|		|		|
		Sarah Sharp		|		|	   Oliver Neukum
	(USB3 and USB core)		|		|	(USB NCM and auto-suspend)
					|		|
				Alan Stern		|
			(EHCI/UHCI/OHCI and USB core)	|
							|
							|
						Felipe Balbi
					(USB3 plat and USB gadget)

The org chart would help outsiders understand that "this random flame
email" is between two people with a trust link.  If an outsider sees an
email blast from Linus to Greg, they will understand this is a "I trust
you as one of my top lieutenants, and as a maintainer, you fucked up."

There's a couple more benefits from an org chart that would be worth
discussing.

An org chart would be helpful for people submitting patches for the first
time.  If someone submits a patch to a USB driver, they'll know they
really should be listening to feedback from Greg, Alan, Felipe, Oliver,
and me.  If J. Random developer is whinging about coding style issues that
checkpatch didn't catch, the submitter will know that they should take
their feedback with a grain of salt.

(This brings up the issue that there should be a place in the org chart
for trusted reviewers, in the case where they aren't a maintainer of code,
but they do have pull in that corner of the kernel community.)

The org chart is also helpful for showing the "bus factor" of different
parts of the kernel.  If Greg gets hit by a bus, he has four sub-sub
maintainers who could possibly take over maintainership of USB.  Other
kernel subsystems don't have sub-sub maintainers, or even backup
maintainers that could take over if the subsystem maintainer had a family
emergency during the merge window.  An org chart would make those
subsystems that aren't deep enough pretty obvious.

Perhaps which maintainer is next in line should be made explicit.  We have
had people die in the kernel community (like David Brownell), and we
should have a plan for who is the backup maintainer, should the worst
happen.  Greg worked with Alan to ensure that the EHCI driver would
continue to be maintained, and I suspect Alan would be Greg's choice for
USB subsystem maintainership if Greg should kick the bucket.  However, if
Greg wasn't there to ask Alan to be a maintainer for all of USB, or the
four sub-sub maintainers fought amongst themselves for control of the USB
maintainership, then that would cause a lot of unnecessary community
strife.

We could have people's photos attached to their names, so that it's easier
for people who are new the community to find people at conferences, and
know who they're talking to.

Basically, there are a lot of potential positive outcomes of making an org
chart.  Does anyone have any objections to someone making one?

> ... and now you want to 'shut down' the discussion. With all due respect, 
> you started it, you have put out various heavy accusations here and 
> elsewhere, so you might as well take responsibility for it and let the 
> discussion be brought to a conclusion, wherever that may take us, compared 
> to your initial view?

Linus expressed that we should be doing our jobs as kernel maintainers,
rather than "talking around the water cooler" about this issue:

http://lkml.org/lkml/2013/7/18/426

I'm not trying to shut down this discussion.  But please, let's continue
this discussion at KS, away from the court of public opinion.  I would
love for this email to serve as a final summary of my opinion.  We can
use this email to start a conversation at KS, and we can argue our
hearts out there about the various points.

Just please, let me do my job as a kernel maintainer, and please stop
replying to this conversation.  I can only write so many long emails a
day without it cutting into my time for writing code and debugging USB
issues.

Move on, agree to disagree, and let's discuss this at KS.

Sarah Sharp

Re: mistakes in code vs. maintainer flow mistakes (was: [ 00/19] 3.10.1-stable review)

[Martin Steigerwald]

Am Freitag, 19. Juli 2013, 12:01:27 schrieb Sarah Sharp:
> On Fri, Jul 19, 2013 at 11:22:56AM +0200, Ingo Molnar wrote:
> > * Sarah Sharp <sarah.a.sharp@linux.intel.com> wrote:
[…]
> "Respect" means different things to different people.  Here's a list of
> potentially disrespectful behaviors:
> 
>  * cussing
>  * belittling statements
>  * demeaning sarcasm
>  * telling someone to SHUT THE FUCK UP
>  * overuse of ALL CAPS to prove a point
>  * encouraging suicide (telling someone to go kill themselves)
>  * hysteria (inappropriate over-reaction to a bad situation)
>  * name calling (calling someone stupid, a moron, etc)
>  * insulting someone's technical skills
>  * making people feel inferior
>  * rewriting someone's code and submitting it without credit to them
>  * ...and not apologizing for these behaviors when someone proves you
>    are wrong about the situation, or over-reacting.
> 
> When these behaviors are combined with giving negative feedback on
> someone's behavior, some developers may perceive the email as a personal
> attack.  That's why I advocate minimizing these behaviors in
> communications between Linus and his lieutenants about their bad
> behavior as maintainers.

I have one note about what you wrote and I see similar wording in other mails 
as I read the thread with interest (but without having much to add to what I 
wrote in my one mail before):

Linus and his lieutenants?

I heard the word "benevolent dictator" in conjunction with Linus, dunno, 
whether he said it or someone else said it or whatnot, but still:

Is the kernel developer community a *military* organisation?

Just wanted to raise awareness to this wording.

As you pointed out repeatedly: Words make a difference.

A huge one, I think.

> Just please, let me do my job as a kernel maintainer, and please stop
> replying to this conversation.  I can only write so many long emails a
> day without it cutting into my time for writing code and debugging USB
> issues.
> 
> Move on, agree to disagree, and let's discuss this at KS.

This however is clearly *your* decision. Its is absolutely and completely your 
decision whether you reply to a mail or not. So I won´t accept any 
responsibility for that and I am fully aware that I have no power to not let 
you do your job as a kernel maintainer. :)

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Re: mistakes in code vs. maintainer flow mistakes (was: [ 00/19] 3.10.1-stable review)

[Steven Rostedt]

On Fri, 2013-07-19 at 12:01 -0700, Sarah Sharp wrote:
> Move on, agree to disagree, and let's discuss this at KS.

+1

(Sorry for the reply ;-)

-- Steve

Re: mistakes in code vs. maintainer flow mistakes (was: [ 00/19] 3.10.1-stable review)

[Kurt H Maier]

On Fri, Jul 19, 2013 at 12:01:27PM -0700, Sarah Sharp wrote:
> 
> I'm not trying to shut down this discussion.  But please, let's continue
> this discussion at KS, away from the court of public opinion.  I would
> love for this email to serve as a final summary of my opinion.  We can
> use this email to start a conversation at KS, and we can argue our
> hearts out there about the various points.

Well more than half your argument is about how "the court of public
opinion" regards interactions on the mailing list.  Why is this
discussion exempt?

> 
> Just please, let me do my job as a kernel maintainer, and please stop
> replying to this conversation.  I can only write so many long emails a
> day without it cutting into my time for writing code and debugging USB
> issues.
> 

You should have thought about that before you posted your assault on
free expression to every single social media outlet you have access to,
With any luck, next time, you will.

khm

Re: [ATTEND] How to act on LKML

[Geert Uytterhoeven]

On Fri, Jul 19, 2013 at 8:42 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Fri, Jul 19, 2013 at 7:08 AM, Ingo Molnar <mingo@kernel.org> wrote:
>>
>> * Felipe Contreras <felipe.contreras@gmail.com> wrote:
>
>>> As Linus already pointed out, not everybody has to work with everybody.
>>
>> That's not the point though, the point is to potentially roughly double
>> the creative brain capacity of the Linux kernel project.
>
> Unfortunately that's impossible; we all know there aren't as many
> women programmers as there are men. So there's absolutely *nothing*
> the Linux kernel can do to double the creative brain capacity of the
> Linux kernel project (at least with respect to women).

There may be less women programmers than men programmers, but that
doesn't say anything about the ratio of female Linux kernel hackers vs.
female programmers.

So let's hope we can prove you wrong soon ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[James Bottomley]

On Fri, 2013-07-19 at 14:56 -0400, Steven Rostedt wrote:
> On Fri, 2013-07-19 at 13:42 -0500, Felipe Contreras wrote:
> 
> > But you are avoiding the question as well; do you think there's
> > something fundamentally different about the female brain that makes
> > them more susceptible to personal attacks? If yes, where is the
> > scientific evidence? If there's no evidence, then it's merely an
> > opinion that is not shared by others (e.g. me), and if no, then
> > whatever the men can take, the women can take as well, so nothing
> > needs to change.
> 
> I don't know bout susceptible to personal attacks, but I have two
> teenage daughters and I can't figure them out yet. I'll say something
> that I think might get them upset and they are fine with it. Then I'll
> say something, where I see no harm, and suddenly I'm the most evil
> person in the world and they go all emotional on me.

I'm afraid I've got bad news for you:  That's not a male/female thing,
that's a teenage thing.  I'm also afraid that it's set to continue for a
while yet.

> Women are too complex for me to figure out. Perhaps men are just too
> simple minded (my wife keeps telling me that). Or perhaps it's just
> me ;-)

If you're basing your entire theory on male/female interaction on
teenagers, then I'm afraid your wife might be on to something ...

James

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Steven Rostedt]

On Fri, 2013-07-19 at 13:33 -0700, James Bottomley wrote:

> If you're basing your entire theory on male/female interaction on
> teenagers, then I'm afraid your wife might be on to something ...

No, it's also based on interaction with my Wife and her sister too ;-)

-- Steve

Re: Maybe it's time to shut this thread down (Was: Re: [ 00/19] 3.10.1-stable review)

[Sarah Sharp]

On Fri, Jul 19, 2013 at 04:03:24PM -0400, Kurt H Maier wrote:
> On Fri, Jul 19, 2013 at 12:01:27PM -0700, Sarah Sharp wrote:
> > 
> > I'm not trying to shut down this discussion.  But please, let's continue
> > this discussion at KS, away from the court of public opinion.  I would
> > love for this email to serve as a final summary of my opinion.  We can
> > use this email to start a conversation at KS, and we can argue our
> > hearts out there about the various points.
> 
> Well more than half your argument is about how "the court of public
> opinion" regards interactions on the mailing list.  Why is this
> discussion exempt?

Come to KS!  You're more than welcome to discuss this with us there.

With some schedule wrangling, I think we can make the session on LKML
communication styles take place on the overlapping day between KS and
LinuxCon.  That should allow anyone from the wider open source community
that wants to participate in this conversation do so.

Sarah Sharp

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 3407 bytes --]

On Fri, 19 Jul 2013 16:43:53 -0400 Steven Rostedt <rostedt@goodmis.org> wrote:

> On Fri, 2013-07-19 at 13:33 -0700, James Bottomley wrote:
> 
> > If you're basing your entire theory on male/female interaction on
> > teenagers, then I'm afraid your wife might be on to something ...
> 
> No, it's also based on interaction with my Wife and her sister too ;-)
> 

I genuinely think the gender difference is a distraction.  The simple fact is
that people are different.  Wildly amazingly beautifully different.

Certainly some metrics have starkly different averages for men than women,
and there can be biological and social drivers of that.  But those metrics
very often vary greatly among men and among women.

But it's really people that are different.

Some people are very perceptive of, and responsive to, those differences.
They are able and willing to listen and understand and adjust.  They try to
fit in with others.  I know a few people like that and I am staggered by how
effectively they bond with other people.

Other people are blind to the differences.  They expect everyone to be just
like themselves.  When the reality shows that isn't true they create coarse
stereotypes to allow them to pigeon hole others.  This naturally leads to
prejudice and sometimes to hate.  And I know a few people like that too -
maybe not quite the extreme, but certainly closer to that extreme than me.


I believe that the abstract/mathematical/literal abilities that allow someone
to be good at software development is inversely correlated with the
holistic/forgiving/flexible abilities that allow someone to be good at
understanding others.

One needs to care deeply about small details.  The other needs to work with
hints and suggestions and accept that precision is simply not available.

I know for myself that such understanding of people as I have has developed
slowly due to hard work, patience from a loving wife and others, and from me
stepping well outside my comfort zone - where as the mathematical ability
was obvious in kindergarten and never needed any encouragement.

And the people I know who are very good with other people are about as
comfortable with technology as I am with strangers (i.e. not very).

If this negative correlation is true, then it says something very important
about our community.  I don't think there is any need for me to spell it out.

I think the recent discussion demonstrates this quite clearly.  Lots of
beating on chests, very little meeting of minds.  Lots of talk about
technical solutions (or non-solutions), very little suggestion of
acknowledgement, accommodation or compromise.
[some - yes.  But not much]

Maybe that is just who we are.  Yes, we are sometimes blind to differences in
others and can lead us to hurt and repel them.  But that blindness allows us
to focus on excellence in technology and so it is worth it.
Or maybe that is only who were were.  Maybe we've got the technology pretty
much under control and we (individuals) can choose to put more effort into
listening to people who are very different to us.  Stop accepting the fact
that we "just don't understand some people" and use our not inconsiderable
intellect find some understanding.

(and no, I don't completely understand my wife either, but I'm sure I
understand her better now than I once did).

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ATTEND] How to act on LKML

[Felipe Contreras]

On Fri, Jul 19, 2013 at 3:03 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Fri, Jul 19, 2013 at 8:42 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Fri, Jul 19, 2013 at 7:08 AM, Ingo Molnar <mingo@kernel.org> wrote:
>>>
>>> * Felipe Contreras <felipe.contreras@gmail.com> wrote:
>>
>>>> As Linus already pointed out, not everybody has to work with everybody.
>>>
>>> That's not the point though, the point is to potentially roughly double
>>> the creative brain capacity of the Linux kernel project.
>>
>> Unfortunately that's impossible; we all know there aren't as many
>> women programmers as there are men. So there's absolutely *nothing*
>> the Linux kernel can do to double the creative brain capacity of the
>> Linux kernel project (at least with respect to women).
>
> There may be less women programmers than men programmers, but that
> doesn't say anything about the ratio of female Linux kernel hackers vs.
> female programmers.

I think it does, because Linux kernel programmers is a subset of
programmers; the very best and very low-level. Unless women
programmers are disproportionately biased towards low-level, and they
are significantly better than their male counterparts, I wouldn't be
holding my breath.

The best case scenario is that we are equal in that regard, in which
case you probably would expect to double or triple the number of
female programmers in Linux thanks to outreach programs, but certainly
not match the amount of male ones.

> So let's hope we can prove you wrong soon ;-)

I think you need more than "hope" to change one of the fundamental
rules of LKML; be open and honest, even if that means expressing your
opinion in a way that others might consider offensive and colorful.

-- 
Felipe Contreras

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]

On Fri, 2013-07-19 at 13:42 -0500, Felipe Contreras wrote:
> On Fri, Jul 19, 2013 at 7:08 AM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Felipe Contreras <felipe.contreras@gmail.com> wrote:
> 
> >> As Linus already pointed out, not everybody has to work with everybody.
> >
> > That's not the point though, the point is to potentially roughly double
> > the creative brain capacity of the Linux kernel project.
> 
> Unfortunately that's impossible; we all know there aren't as many
> women programmers as there are men.

In some countries, though not all.

But we also know (or should realise) that the gender ratio among
programmers in general is much less unbalanced than in some free
software communities including the Linux kernel developers.

> So there's absolutely *nothing*
> the Linux kernel can do to double the creative brain capacity of the
> Linux kernel project (at least with respect to women).
>
> At best that is a societal/academic/professional issue, not a Linux issue.
[...]

There is a broader societal issue, but that doesn't mean that there
isn't also a problem at the level of individual developer communities.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [Ksummit-2013-discuss] Maybe it's time to shut this thread down (Was: Re: [ 00/19] 3.10.1-stable review)

[Daniel Phillips]

On 07/18/2013 03:54 PM, Sarah Sharp wrote:
> Let's shift this discussion away from the terms "abuse" and
> "professionalism" to "respect" and "civility".

Brilliant, and +1 for a session at KS. In the mean time, why don't we 
all try to demonstrate the real meaning of respect and civility, by 
practising it henceforth on LKML? KS ought to be about clarification, 
reinforcement and specific techniques, as opposed to the question of 
whether respect and civility are desirable in the first place. Nobody 
needs to wait for KS to learn the basic truth they already know in their 
heart.

Regards,

Daniel

Re: [Ksummit-2013-discuss] Maybe it's time to shut this thread down (Was: Re: [ 00/19] 3.10.1-stable review)

[Daniel Phillips]

On 07/18/2013 03:54 PM, Sarah Sharp wrote:
> Let's shift this discussion away from the terms "abuse" and
> "professionalism" to "respect" and "civility".

Brilliant, and +1 for a session at KS. In the mean time, why don't we 
all try to demonstrate the real meaning of respect and civility, by 
practising it henceforth on LKML? KS ought to be about clarification, 
reinforcement and specific techniques, as opposed to the question of 
whether respect and civility are desirable in the first place. Nobody 
needs to wait for KS to learn the basic truth they already know in their 
heart.

Regards,

Daniel

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Daniel Phillips]

On 07/20/2013 12:36 PM, Felipe Contreras wrote:
> I think you need more than "hope" to change one of the fundamental
> rules of LKML; be open and honest, even if that means expressing your
> opinion in a way that others might consider offensive and colorful.

Logical fallacy type: bifurcation. You can be open and honest without 
being offensive or abusive.

Regards,

Daniel

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Daniel Phillips]

On 07/20/2013 12:36 PM, Felipe Contreras wrote:
> I think you need more than "hope" to change one of the fundamental
> rules of LKML; be open and honest, even if that means expressing your
> opinion in a way that others might consider offensive and colorful.

Logical fallacy type: bifurcation. You can be open and honest without 
being offensive or abusive.

Regards,

Daniel

Re: [ 00/19] 3.10.1-stable review

[Rob Landley]

On 07/15/2013 09:01:56 PM, Joe Perches wrote:
> On Tue, 2013-07-16 at 11:54 +1000, NeilBrown wrote:
> > On Mon, 15 Jul 2013 16:50:52 -0700 Joe Perches <joe@perches.com>  
> wrote:
> >
> > > On Tue, 2013-07-16 at 09:42 +1000, NeilBrown wrote:
> > > > Being "polite" without being "nice" is quite possible.
> > > > It even has a name:  Diplomacy.
> > >
> > > And we all know how circular/indirect/implied/useless
> > > some of those diplomatic conversations can be.
> > >
> > > Just remember to bring a 'Big Stick' and don't be shy
> > > when it's necessary to display it.
> >
> > The behaviour you appear to be advocating is what is generally  
> called
> > "bullying".
> 
> Nope.  It's called not being a pushover and being
> direct, clear and not just being unnecessarily forceful.

Linux-kernel is an _epicially_ self-selected group.

I expect the vast majority of people would be on Neil's side of this  
argument, not Joe's. But they've already walked away, and are not  
coming back.

Rob

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Ric Wheeler]

On 07/20/2013 01:04 PM, Ben Hutchings wrote:
> n Fri, 2013-07-19 at 13:42 -0500, Felipe Contreras wrote:
>> >On Fri, Jul 19, 2013 at 7:08 AM, Ingo Molnar<mingo@kernel.org>  wrote:
>>> > >
>>> > >* Felipe Contreras<felipe.contreras@gmail.com>  wrote:
>> >
>>>> > >>As Linus already pointed out, not everybody has to work with everybody.
>>> > >
>>> > >That's not the point though, the point is to potentially roughly double
>>> > >the creative brain capacity of the Linux kernel project.
>> >
>> >Unfortunately that's impossible; we all know there aren't as many
>> >women programmers as there are men.
> In some countries, though not all.
>
> But we also know (or should realise) that the gender ratio among
> programmers in general is much less unbalanced than in some free
> software communities including the Linux kernel developers.
>

Just a couple of data points to add.

When I was in graduate school in Israel, we had more women doing their phd then 
men. Not a huge sample, but it was interesting.

The counter sample is the number of coding women we have at Red Hat in the 
kernel team. We are around zero per cent. Certainly a sign that we need to do 
better, regardless of the broader community challenges...

Ric

Re: mistakes in code vs. maintainer flow mistakes (was: [ 00/19] 3.10.1-stable review)

[Ingo Molnar]

* Sarah Sharp <sarah.a.sharp@linux.intel.com> wrote:

> On Fri, Jul 19, 2013 at 11:22:56AM +0200, Ingo Molnar wrote:
> > 
> > * Sarah Sharp <sarah.a.sharp@linux.intel.com> wrote:
> > 
> > > On Thu, Jul 18, 2013 at 12:39:07PM +0200, Ingo Molnar wrote:
> > > > 
> > > > * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > > > 
> > > > > On Mon, Jul 15, 2013 at 1:41 PM, Sarah Sharp
> > > > > <sarah.a.sharp@linux.intel.com> wrote:
> > > > > >
> > > > > > Oh, FFS, I just called out on private email for "playing the victim
> > > > > > card".  I will repeat: this is not just about me, or other minorities.
> > > > > > I should not have to ask for professional behavior on the mailing lists.
> > > > > > Professional behavior should be the default.
> > > > > 
> > > > 
> > > > > [...]
> > > > > 
> > > > > Because if you want me to "act professional", I can tell you that I'm 
> > > > > not interested. I'm sitting in my home office wearign a bathrobe. The 
> > > > > same way I'm not going to start wearing ties, I'm *also* not going to 
> > > > > buy into the fake politeness, the lying, the office politics and 
> > > > > backstabbing, the passive aggressiveness, and the buzzwords. Because 
> > > > > THAT is what "acting professionally" results in: people resort to all 
> > > > > kinds of really nasty things because they are forced to act out their 
> > > > > normal urges in unnatural ways.
> > > > 
> > > > Sarah, that's a pretty potent argument by Linus, that "acting 
> > > > professionally" risks replacing a raw but honest culture with a
> > > > polished but dishonest culture - which is harmful to developing
> > > > good technology.
> > > > 
> > > > That's a valid concern. What's your reply to that argument?
> > > 
> > > I don't feel the need to comment, because I feel it's a straw man 
> > > argument.  I feel that way because I disagree with the definition of 
> > > professionalism that people have been pushing.
> > 
> > I hope you won't take this as a sign of disrespect, but it's hard to keep 
> > up with your somewhat fluid opinion about what exactly you find 
> > objectionable :-/
> 
> The good news is you're confused because I've been influenced by some of 
> the arguments people have made on this thread.  As a result, my 
> viewpoints may have changed subtly, [...]

It's nice to see such flexiblity!

Thanks for the very detailed description of your opinion, it's a very 
constructive approach.

My opinion is flexible and subject to change as well - and I agree that 
this is better discussed at the KS.

Thanks,

	Ingo

Re: mistakes in code vs. maintainer flow mistakes (was: [ 00/19] 3.10.1-stable review)

[Ingo Molnar]

* Ingo Molnar <mingo@kernel.org> wrote:

> [...]
> 
> ... and now you want to 'shut down' the discussion. With all due 
> respect, you started it, you have put out various heavy accusations here 
> and elsewhere, so you might as well take responsibility for it and let 
> the discussion be brought to a conclusion, wherever that may take us, 
> compared to your initial view?

I'd like to retract this portion of my mail because in hindsight it's 
overly (and undeservedly) harsh and confrontative.

I found your followup description entirely satisfactory, thanks for taking 
the time to write it up and I think it's a good starting point for the 
Kernel Summit discussion.

Thanks,

	Ingo

Re: Maybe it's time to shut this thread down (Was: Re: [ 00/19] 3.10.1-stable review)

[Kurt H Maier]

On Fri, Jul 19, 2013 at 02:44:21PM -0700, Sarah Sharp wrote:
> On Fri, Jul 19, 2013 at 04:03:24PM -0400, Kurt H Maier wrote:
> 
> Come to KS!  You're more than welcome to discuss this with us there.
> 


Thanks for the invitation, but those events don't fit into my schedule.
I hope in my absence you'll find away to empower yourself without
disenfranchising others or reinforcing harmful cis-gender stereotypes.
I wish you a constructive summit!

khm

RE: [Ksummit-2013-discuss] Maybe it's time to shut this thread down (Was: Re: [ 00/19] 3.10.1-stable review)

[Luck, Tony]

On 07/18/2013 03:54 PM, Sarah Sharp wrote:
> Let's shift this discussion away from the terms "abuse" and
> "professionalism" to "respect" and "civility".

And Daniel Philips replied:
> Brilliant, and +1 for a session at KS. In the mean time, why don't we 
> all try to demonstrate the real meaning of respect and civility, by 
> practising it henceforth on LKML

+1 from me too. Using the right terms will help us have a discussion that
focusses on the issues that matter - and avoid getting side-tracked by
things that don't.

Some thoughts on the format of the discussion at KS:

1) Keep it real
    We could come up with hypothetical scenarios on what things people *might* say, and
    how you *might* react and talk for days.  Let's stick to things that actually happened.
    (people's feelings/emotions on seeing specific posts count as "actually happened" for
     this - even if they didn't post a reply ... perhaps especially if they didn't post).
2) Keep it personal
    An extension of keeping it real - none of us represents the thoughts and opinions of
    *every* other developer with whom we share some attribute.  Sarah doesn't speak
    for all young cool programmers any more than I speak for all old uncool ones :-). So stick
    to your own stories, or those of specific people that can't be at KS but ask for their
    tales to be told. [Not sure how well I expressed this one ... I'm trying to avoid the
    issue where someone gets fired up with indignation on behalf of someone else ... who
    isn't actually bothered by whatever happened].
3) Don't bring up ancient history
    From the discussions on this, it looks like many people believe that things are better
    than they were just a few years ago.  Unless someone has the desire to do some
    month-by-month survey and disproves this perception - let's pretend we have a
    one or two year statute of limitations and not keep feuds going for (internet) generations.
4) Perfect is the enemy of good
    Or "You can't please all of the people all of the time". No matter what we do there
    will still be some unhappy people. Life is like that. But we can almost certainly
    make more of the people happier for most of the time. So our goal isn't to solve
    every possible problem (we need to save some topics for future KS :-) we just
    want to make things better than they are, while still allowing for criticism of code.
 
-Tony

RE: [Ksummit-2013-discuss] Maybe it's time to shut this thread down (Was: Re: [ 00/19] 3.10.1-stable review)

[Luck, Tony]

On 07/18/2013 03:54 PM, Sarah Sharp wrote:
> Let's shift this discussion away from the terms "abuse" and
> "professionalism" to "respect" and "civility".

And Daniel Philips replied:
> Brilliant, and +1 for a session at KS. In the mean time, why don't we 
> all try to demonstrate the real meaning of respect and civility, by 
> practising it henceforth on LKML

+1 from me too. Using the right terms will help us have a discussion that
focusses on the issues that matter - and avoid getting side-tracked by
things that don't.

Some thoughts on the format of the discussion at KS:

1) Keep it real
    We could come up with hypothetical scenarios on what things people *might* say, and
    how you *might* react and talk for days.  Let's stick to things that actually happened.
    (people's feelings/emotions on seeing specific posts count as "actually happened" for
     this - even if they didn't post a reply ... perhaps especially if they didn't post).
2) Keep it personal
    An extension of keeping it real - none of us represents the thoughts and opinions of
    *every* other developer with whom we share some attribute.  Sarah doesn't speak
    for all young cool programmers any more than I speak for all old uncool ones :-). So stick
    to your own stories, or those of specific people that can't be at KS but ask for their
    tales to be told. [Not sure how well I expressed this one ... I'm trying to avoid the
    issue where someone gets fired up with indignation on behalf of someone else ... who
    isn't actually bothered by whatever happened].
3) Don't bring up ancient history
    From the discussions on this, it looks like many people believe that things are better
    than they were just a few years ago.  Unless someone has the desire to do some
    month-by-month survey and disproves this perception - let's pretend we have a
    one or two year statute of limitations and not keep feuds going for (internet) generations.
4) Perfect is the enemy of good
    Or "You can't please all of the people all of the time". No matter what we do there
    will still be some unhappy people. Life is like that. But we can almost certainly
    make more of the people happier for most of the time. So our goal isn't to solve
    every possible problem (we need to save some topics for future KS :-) we just
    want to make things better than they are, while still allowing for criticism of code.
 
-Tony

Re: [Ksummit-2013-discuss] Maybe it's time to shut this thread down (Was: Re: [ 00/19] 3.10.1-stable review)

[Daniel Phillips]

On 07/22/2013 09:02 PM, Luck, Tony wrote:
> Some thoughts on the format of the discussion at KS:
>
> ...
>

5) Volunteers are under-represented at Kernel Summit

Volunteers are the "dark matter" of Linux Kernel contribution. They are 
not the "usual suspects" who nearly all have full time jobs now, 
allowing them the time investment to raise their profile sufficiently to 
gain a place at the KS round table. They may not be very vocal. They are 
most probably the first to depart for more pleasant pastures when the 
interaction becomes less than fun. In part because they do not have an 
employer who requires them to stay engaged no matter what.

How do we represent the viewpoint of volunteers? Which for many of us is 
a former life, the memory of which may be starting to fade.

Regards,

Daniel

Re: [Ksummit-2013-discuss] Maybe it's time to shut this thread down (Was: Re: [ 00/19] 3.10.1-stable review)

[Daniel Phillips]

On 07/22/2013 09:02 PM, Luck, Tony wrote:
> Some thoughts on the format of the discussion at KS:
>
> ...
>

5) Volunteers are under-represented at Kernel Summit

Volunteers are the "dark matter" of Linux Kernel contribution. They are 
not the "usual suspects" who nearly all have full time jobs now, 
allowing them the time investment to raise their profile sufficiently to 
gain a place at the KS round table. They may not be very vocal. They are 
most probably the first to depart for more pleasant pastures when the 
interaction becomes less than fun. In part because they do not have an 
employer who requires them to stay engaged no matter what.

How do we represent the viewpoint of volunteers? Which for many of us is 
a former life, the memory of which may be starting to fade.

Regards,

Daniel

Re: mistakes in code vs. maintainer flow mistakes

[Li Zefan]

> Perhaps what might help here is a kernel organizational chart.  A graph
> of who sends pull requests to Linus, and their subsystem maintainers.
> For example, in the USB "branch" there would be:
> 
> 				Linus Torvalds
> 			(Linux kernel release engineer)
> 					|
> 					|
> 				Greg Kroah-Hartman
> 				      (USB)
> 					|
> 					|
> 			-------------------------------------------------
> 			|		|		|		|
> 			|		|		|		|
> 		Sarah Sharp		|		|	   Oliver Neukum
> 	(USB3 and USB core)		|		|	(USB NCM and auto-suspend)
> 					|		|
> 				Alan Stern		|
> 			(EHCI/UHCI/OHCI and USB core)	|
> 							|
> 							|
> 						Felipe Balbi
> 					(USB3 plat and USB gadget)
> 

Nice chart, exccept that the complete chart will in no doubt break 80
characters limit. Actually as the hierarchy is quite flat, I can't
image how long the longest line will be.

Re: mistakes in code vs. maintainer flow mistakes

[Joe Perches]

On Tue, 2013-07-23 at 09:07 +0800, Li Zefan wrote:
> > Perhaps what might help here is a kernel organizational chart.
[]
> the complete chart will in no doubt break 80
> characters limit. Actually as the hierarchy is quite flat, I can't
> image how long the longest line will be.

I think it really doesn't matter unless you want to
generate that from the same information that is
available via git, scripts/get_maintainer.pl and
the MAINTAINERS file.

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Li Zefan]

On 2013/7/21 21:22, Ric Wheeler wrote:
> On 07/20/2013 01:04 PM, Ben Hutchings wrote:
>> n Fri, 2013-07-19 at 13:42 -0500, Felipe Contreras wrote:
>>> >On Fri, Jul 19, 2013 at 7:08 AM, Ingo Molnar<mingo@kernel.org>  wrote:
>>>> > >
>>>> > >* Felipe Contreras<felipe.contreras@gmail.com>  wrote:
>>> >
>>>>> > >>As Linus already pointed out, not everybody has to work with everybody.
>>>> > >
>>>> > >That's not the point though, the point is to potentially roughly double
>>>> > >the creative brain capacity of the Linux kernel project.
>>> >
>>> >Unfortunately that's impossible; we all know there aren't as many
>>> >women programmers as there are men.
>> In some countries, though not all.
>>
>> But we also know (or should realise) that the gender ratio among
>> programmers in general is much less unbalanced than in some free
>> software communities including the Linux kernel developers.
>>
> 
> Just a couple of data points to add.
> 
> When I was in graduate school in Israel, we had more women doing their phd then men. Not a huge sample, but it was interesting.
> 
> The counter sample is the number of coding women we have at Red Hat in the kernel team. We are around zero per cent. Certainly a sign that we need to do better, regardless of the broader community challenges...
> 

IT companies in China, they try to make sure there's at least one (most the
time the result is just one) female developer/tester in a team, and a team
is ~10 people. Even if it's a kernel team, but it's harder to meet.

Don't know if the same strategy is applied in other countries.

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Steven Rostedt]

On Tue, 2013-07-23 at 09:26 +0800, Li Zefan wrote:

> IT companies in China, they try to make sure there's at least one (most the
> time the result is just one) female developer/tester in a team, and a team
> is ~10 people. Even if it's a kernel team, but it's harder to meet.
> 
> Don't know if the same strategy is applied in other countries.

Just my observation, but it seems that I see more women in tech from the
Asian countries than from the US.

Watching my two teenage daughters grow up here as well as their friends,
the focus of our schools still seem more bent on being good in sports
than in academics, and even worse for science. Sports for girls happen
to be much more serious than when I was in school. Being a "nerd" for a
boy is starting to get a bit more acceptance (see Big Bang Theory), but
for girls they seem a bit more harsh. At least from what I can tell by
watching how things are with my kids and their friends. One of the
friends of my daughter, who does very well in school, hides her grades
and "pretends" to be stupid. This is really a sad state of affairs if
you ask me :-(

-- Steve

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Li Zefan]

On 2013/7/23 9:39, Steven Rostedt wrote:
> On Tue, 2013-07-23 at 09:26 +0800, Li Zefan wrote:
> 
>> IT companies in China, they try to make sure there's at least one (most the
>> time the result is just one) female developer/tester in a team, and a team
>> is ~10 people. Even if it's a kernel team, but it's harder to meet.
>>
>> Don't know if the same strategy is applied in other countries.
> 
> Just my observation, but it seems that I see more women in tech from the
> Asian countries than from the US.
> 
> Watching my two teenage daughters grow up here as well as their friends,
> the focus of our schools still seem more bent on being good in sports
> than in academics, and even worse for science. Sports for girls happen
> to be much more serious than when I was in school. Being a "nerd" for a
> boy is starting to get a bit more acceptance (see Big Bang Theory), but
> for girls they seem a bit more harsh. At least from what I can tell by
> watching how things are with my kids and their friends. One of the
> friends of my daughter, who does very well in school, hides her grades
> and "pretends" to be stupid. This is really a sad state of affairs if
> you ask me :-(
> 

In china we are in the opposite. In college girls like to stay in school
library to study, and in general they get better scores than boys, and
they don't like sports. But being good in study is not the same as being
good at programming, and in fact they are not keen in coding!

And I think IT companies in China tend to lower their requirements when
the job interviewee is a female.

Re: [ 00/19] 3.10.1-stable review

[Rogelio Serrano]

Hi Sarah,

kinda reminds me of... baboons... its natural among mammals i guess...

Why hierarchy creates a destructive force within the human psyche (by
dr. Robert Sapolsky)
http://www.youtube.com/watch?v=A4UMyTnlaMY&feature=share


On Mon, Jul 15, 2013 at 11:52 PM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
> On Fri, 12 Jul 2013 18:17:08 +0200, Ingo Molnar <mingo@kernel.org> wrote:
>> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>
>> > On Fri, Jul 12, 2013 at 8:47 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
>> > >
>> > > I tend to hold things off after -rc4 because you scare me more than Greg
>> > > does ;-)
>> >
>> > Have you guys *seen* Greg? The guy is a freakish giant. He *should*
>> > scare you. He might squish you without ever even noticing.
>>
>> Greg might be a giant and he might squish people without ever even
>> noticing, but that's just a grave, deadly physical threat no real kernel
>> hacker ever feels threatened by. (Not much can hurt us deep in our dark
>> basements after all, except maybe earthquakes, gamma ray eruptions and Mom
>> trying to clean up around the computers.)
>>
>> So Greg, if you want it all to change, create some _real_ threat: be frank
>> with contributors and sometimes swear a bit. That will cut your mailqueue
>> in half, promise!
>
> On Fri, 12 Jul 2013 08:22:27 -0700, Linus wrote:
>> Greg, the reason you get a lot of stable patches seems to be that you
>> make it easy to act as a door-mat. Clearly at least some people say "I
>> know this patch isn't important enough to send to Linus, but I know Greg
>> will silently accept it after the fact, so I'll just wait and mark it
>> for stable".
>>
>> You may need to learn to shout at people.
>
> Seriously, guys?  Is this what we need in order to get improve -stable?
> Linus Torvalds is advocating for physical intimidation and violence.
> Ingo Molnar and Linus are advocating for verbal abuse.
>
> Not *fucking* cool.  Violence, whether it be physical intimidation,
> verbal threats or verbal abuse is not acceptable.  Keep it professional
> on the mailing lists.
>
> Let's discuss this at Kernel Summit where we can at least yell at each
> other in person.  Yeah, just try yelling at me about this.  I'll roar
> right back, louder, for all the people who lose their voice when they
> get yelled at by top maintainers.  I won't be the nice girl anymore.
>
> Sarah Sharp
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Felipe Contreras]

On Sat, Jul 20, 2013 at 8:02 PM, Daniel Phillips
<d.phillips@partner.samsung.com> wrote:
> On 07/20/2013 12:36 PM, Felipe Contreras wrote:
>> I think you need more than "hope" to change one of the fundamental
>> rules of LKML; be open and honest, even if that means expressing your
>> opinion in a way that others might consider offensive and colorful.
>
> Logical fallacy type: bifurcation. You can be open and honest without
> being offensive or abusive.

You are mistaken, that is not what the false dichotomy fallacy means.
I'm not saying you have to be A (open and honest), or B (polite), and
that you can't be both, if that's what you arguing (which seems to be
the case), you are wrong, and to argue against that position would be
a straw man fallacy.

Your mistaken fallacy seems to be that you think one can *always* be
both A (open and honest), and B (polite), I'm not sure if there's a
name for that fallacy, but you don't provide any evidence for that
claim.

And even supposing that such an obvious fallacy (that one can *always*
be both open and honest, and polite) was true, the fact that something
*can* be done, doesn't mean it *should* be done.

-- 
Felipe Contreras

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Felipe Contreras]

On Sat, Jul 20, 2013 at 8:02 PM, Daniel Phillips
<d.phillips@partner.samsung.com> wrote:
> On 07/20/2013 12:36 PM, Felipe Contreras wrote:
>> I think you need more than "hope" to change one of the fundamental
>> rules of LKML; be open and honest, even if that means expressing your
>> opinion in a way that others might consider offensive and colorful.
>
> Logical fallacy type: bifurcation. You can be open and honest without
> being offensive or abusive.

You are mistaken, that is not what the false dichotomy fallacy means.
I'm not saying you have to be A (open and honest), or B (polite), and
that you can't be both, if that's what you arguing (which seems to be
the case), you are wrong, and to argue against that position would be
a straw man fallacy.

Your mistaken fallacy seems to be that you think one can *always* be
both A (open and honest), and B (polite), I'm not sure if there's a
name for that fallacy, but you don't provide any evidence for that
claim.

And even supposing that such an obvious fallacy (that one can *always*
be both open and honest, and polite) was true, the fact that something
*can* be done, doesn't mean it *should* be done.

-- 
Felipe Contreras

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[James Bottomley]

On Tue, 2013-07-23 at 19:51 -0500, Felipe Contreras wrote:
> On Sat, Jul 20, 2013 at 8:02 PM, Daniel Phillips
> <d.phillips@partner.samsung.com> wrote:
> > On 07/20/2013 12:36 PM, Felipe Contreras wrote:
> >> I think you need more than "hope" to change one of the fundamental
> >> rules of LKML; be open and honest, even if that means expressing your
> >> opinion in a way that others might consider offensive and colorful.
> >
> > Logical fallacy type: bifurcation. You can be open and honest without
> > being offensive or abusive.
> 
> You are mistaken, that is not what the false dichotomy fallacy means.
> I'm not saying you have to be A (open and honest), or B (polite), and
> that you can't be both, if that's what you arguing (which seems to be
> the case), you are wrong, and to argue against that position would be
> a straw man fallacy.
> 
> Your mistaken fallacy seems to be that you think one can *always* be
> both A (open and honest), and B (polite), I'm not sure if there's a
> name for that fallacy, but you don't provide any evidence for that
> claim.

It's not actually one of the original logical fallacies, but it's called
argument to moderation or false compromise: The fallacy is the
assumption that the original statements represent extremal positions of
a continuum so there must always be middle ground which represents the
correct statement.  To those accepting the fallacy making the middle
ground statement by that fact alone demonstrates the invalidity of the
previous proposition.

I think it's not in the original fallacies because they come from Greek
rhetoric and the Greeks believed dialectic: the taking opposite
positions and arguing them thoroughly.  It's only with the advent of
Western European political systems that we're conditioned to seek
compromise without rigorous examination.  This actually makes argument
to moderation one of the most effective rhetorical tools in use today
for discrediting an opponent's argument without actually addressing it.

James

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[James Bottomley]

On Tue, 2013-07-23 at 19:51 -0500, Felipe Contreras wrote:
> On Sat, Jul 20, 2013 at 8:02 PM, Daniel Phillips
> <d.phillips@partner.samsung.com> wrote:
> > On 07/20/2013 12:36 PM, Felipe Contreras wrote:
> >> I think you need more than "hope" to change one of the fundamental
> >> rules of LKML; be open and honest, even if that means expressing your
> >> opinion in a way that others might consider offensive and colorful.
> >
> > Logical fallacy type: bifurcation. You can be open and honest without
> > being offensive or abusive.
> 
> You are mistaken, that is not what the false dichotomy fallacy means.
> I'm not saying you have to be A (open and honest), or B (polite), and
> that you can't be both, if that's what you arguing (which seems to be
> the case), you are wrong, and to argue against that position would be
> a straw man fallacy.
> 
> Your mistaken fallacy seems to be that you think one can *always* be
> both A (open and honest), and B (polite), I'm not sure if there's a
> name for that fallacy, but you don't provide any evidence for that
> claim.

It's not actually one of the original logical fallacies, but it's called
argument to moderation or false compromise: The fallacy is the
assumption that the original statements represent extremal positions of
a continuum so there must always be middle ground which represents the
correct statement.  To those accepting the fallacy making the middle
ground statement by that fact alone demonstrates the invalidity of the
previous proposition.

I think it's not in the original fallacies because they come from Greek
rhetoric and the Greeks believed dialectic: the taking opposite
positions and arguing them thoroughly.  It's only with the advent of
Western European political systems that we're conditioned to seek
compromise without rigorous examination.  This actually makes argument
to moderation one of the most effective rhetorical tools in use today
for discrediting an opponent's argument without actually addressing it.

James

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Steven Rostedt]

On Tue, 2013-07-23 at 18:26 -0700, James Bottomley wrote:

> I think it's not in the original fallacies because they come from Greek
> rhetoric and the Greeks believed dialectic: the taking opposite
> positions and arguing them thoroughly.  It's only with the advent of
> Western European political systems that we're conditioned to seek
> compromise without rigorous examination.  This actually makes argument
> to moderation one of the most effective rhetorical tools in use today
> for discrediting an opponent's argument without actually addressing it.

What? Really? You mean the truth doesn't lie in the middle between
evolution and creationism?

-- Steve

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Steven Rostedt]

On Tue, 2013-07-23 at 18:26 -0700, James Bottomley wrote:

> I think it's not in the original fallacies because they come from Greek
> rhetoric and the Greeks believed dialectic: the taking opposite
> positions and arguing them thoroughly.  It's only with the advent of
> Western European political systems that we're conditioned to seek
> compromise without rigorous examination.  This actually makes argument
> to moderation one of the most effective rhetorical tools in use today
> for discrediting an opponent's argument without actually addressing it.

What? Really? You mean the truth doesn't lie in the middle between
evolution and creationism?

-- Steve

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Paul Gortmaker]

On Tue, Jul 23, 2013 at 9:26 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Tue, 2013-07-23 at 19:51 -0500, Felipe Contreras wrote:
>> On Sat, Jul 20, 2013 at 8:02 PM, Daniel Phillips
>> <d.phillips@partner.samsung.com> wrote:
>> > On 07/20/2013 12:36 PM, Felipe Contreras wrote:
>> >> I think you need more than "hope" to change one of the fundamental
>> >> rules of LKML; be open and honest, even if that means expressing your
>> >> opinion in a way that others might consider offensive and colorful.
>> >
>> > Logical fallacy type: bifurcation. You can be open and honest without
>> > being offensive or abusive.
>>
>> You are mistaken, that is not what the false dichotomy fallacy means.
>> I'm not saying you have to be A (open and honest), or B (polite), and
>> that you can't be both, if that's what you arguing (which seems to be
>> the case), you are wrong, and to argue against that position would be
>> a straw man fallacy.
>>
>> Your mistaken fallacy seems to be that you think one can *always* be
>> both A (open and honest), and B (polite), I'm not sure if there's a
>> name for that fallacy, but you don't provide any evidence for that
>> claim.
>
> It's not actually one of the original logical fallacies, but it's called
> argument to moderation or false compromise: The fallacy is the
> assumption that the original statements represent extremal positions of
> a continuum so there must always be middle ground which represents the
> correct statement.  To those accepting the fallacy making the middle
> ground statement by that fact alone demonstrates the invalidity of the
> previous proposition.

And when so many of us had convinced ourselves that this thread could
not possibly descend any further into the off-topic weeds...  Good job.
That assumption has now been shattered by bringing in ancient Greece.

Given that, I'd like to propose a KS topic that covers Adam Smith, and
John Stuart Mill,  Leviathan by Hobbes, and The Politics by Aristotle.

C'mon folks.  This is beyond silly.  Let us look at the things that we
can really change, or at least influence change within.  Things that
really matter to linux today and tomorrow.

P.
---

>
> I think it's not in the original fallacies because they come from Greek
> rhetoric and the Greeks believed dialectic: the taking opposite
> positions and arguing them thoroughly.  It's only with the advent of
> Western European political systems that we're conditioned to seek
> compromise without rigorous examination.  This actually makes argument
> to moderation one of the most effective rhetorical tools in use today
> for discrediting an opponent's argument without actually addressing it.
>
> James
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Paul Gortmaker]

On Tue, Jul 23, 2013 at 9:26 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Tue, 2013-07-23 at 19:51 -0500, Felipe Contreras wrote:
>> On Sat, Jul 20, 2013 at 8:02 PM, Daniel Phillips
>> <d.phillips@partner.samsung.com> wrote:
>> > On 07/20/2013 12:36 PM, Felipe Contreras wrote:
>> >> I think you need more than "hope" to change one of the fundamental
>> >> rules of LKML; be open and honest, even if that means expressing your
>> >> opinion in a way that others might consider offensive and colorful.
>> >
>> > Logical fallacy type: bifurcation. You can be open and honest without
>> > being offensive or abusive.
>>
>> You are mistaken, that is not what the false dichotomy fallacy means.
>> I'm not saying you have to be A (open and honest), or B (polite), and
>> that you can't be both, if that's what you arguing (which seems to be
>> the case), you are wrong, and to argue against that position would be
>> a straw man fallacy.
>>
>> Your mistaken fallacy seems to be that you think one can *always* be
>> both A (open and honest), and B (polite), I'm not sure if there's a
>> name for that fallacy, but you don't provide any evidence for that
>> claim.
>
> It's not actually one of the original logical fallacies, but it's called
> argument to moderation or false compromise: The fallacy is the
> assumption that the original statements represent extremal positions of
> a continuum so there must always be middle ground which represents the
> correct statement.  To those accepting the fallacy making the middle
> ground statement by that fact alone demonstrates the invalidity of the
> previous proposition.

And when so many of us had convinced ourselves that this thread could
not possibly descend any further into the off-topic weeds...  Good job.
That assumption has now been shattered by bringing in ancient Greece.

Given that, I'd like to propose a KS topic that covers Adam Smith, and
John Stuart Mill,  Leviathan by Hobbes, and The Politics by Aristotle.

C'mon folks.  This is beyond silly.  Let us look at the things that we
can really change, or at least influence change within.  Things that
really matter to linux today and tomorrow.

P.
---

>
> I think it's not in the original fallacies because they come from Greek
> rhetoric and the Greeks believed dialectic: the taking opposite
> positions and arguing them thoroughly.  It's only with the advent of
> Western European political systems that we're conditioned to seek
> compromise without rigorous examination.  This actually makes argument
> to moderation one of the most effective rhetorical tools in use today
> for discrediting an opponent's argument without actually addressing it.
>
> James
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Steven Rostedt]

On Tue, 2013-07-23 at 21:48 -0400, Paul Gortmaker wrote:
> C'mon folks.  This is beyond silly.  Let us look at the things that we
> can really change, or at least influence change within.  Things that
> really matter to linux today and tomorrow.

Ah, so there is middle ground between creationism and evolution!

-- Steve

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Steven Rostedt]

On Tue, 2013-07-23 at 21:48 -0400, Paul Gortmaker wrote:
> C'mon folks.  This is beyond silly.  Let us look at the things that we
> can really change, or at least influence change within.  Things that
> really matter to linux today and tomorrow.

Ah, so there is middle ground between creationism and evolution!

-- Steve

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Daniel Phillips]

On 07/24/2013 12:51 AM, Felipe Contreras wrote:
> Your mistaken fallacy seems to be that you think one can *always* be
> both A (open and honest), and B (polite)...

You are are right, I do think that you can *always* be both open and 
honest, and polite. I do not believe that I am mistaken. And I hope that 
you will come to agree with me in the not too distant future.

Regards,

Daniel

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Daniel Phillips]

On 07/24/2013 12:51 AM, Felipe Contreras wrote:
> Your mistaken fallacy seems to be that you think one can *always* be
> both A (open and honest), and B (polite)...

You are are right, I do think that you can *always* be both open and 
honest, and polite. I do not believe that I am mistaken. And I hope that 
you will come to agree with me in the not too distant future.

Regards,

Daniel

Re: [ 00/19] 3.10.1-stable review

[Florian Holz]

Hi,

just a short comment.

I think, this snippet shows the key point in this argument:

At 15.07.2013 21:53 CEST +02:00 Sarah Sharp wrote:
> Good lord.  So anyone that is one of your "top maintainers" could be
> exposed to your verbal abuse just because they "should have known
> better"?
> 
> You know what the definition of an abuser is?  Someone that seeks out
> victims that they know will "just take it" and keep the abuse "between
> the two of them".  They pick victims that won't fight back or report the
> abuse.
> 
Sarah introduced the term "abuse" like in the first paragraph into the
discussion while complaining about the tone in some statements. It's her
claim, that all non-"polite" statements are an "abuse".

In the second paragraph, then she argues that "abuse" should be
prevented, using some definition of "abuse".

The claim that the unwanted kind of statements are really a kind of
abuse is still unfounded. She could have proven it -- eg by using
its/her/a definition -- but she only used this definition as foundation
to dislike the non-"polite" statements.

Imho this is just circular reasoning [1]
> (I) dislike -> (I regard as) impolite -> kind of abuse -> to be disliked (by all)
and so has no substance up to now. Maybe, logical package management
would have recognized this unmet dependency ;)

Disclaimer:
I dont' question the implication "abuse -> to be disliked".

Flo

[1] https://en.wikipedia.org/wiki/Circular_reasoning

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[James Bottomley]

On Tue, 2013-07-23 at 21:38 -0400, Steven Rostedt wrote:
> On Tue, 2013-07-23 at 18:26 -0700, James Bottomley wrote:
> 
> > I think it's not in the original fallacies because they come from Greek
> > rhetoric and the Greeks believed dialectic: the taking opposite
> > positions and arguing them thoroughly.  It's only with the advent of
> > Western European political systems that we're conditioned to seek
> > compromise without rigorous examination.  This actually makes argument
> > to moderation one of the most effective rhetorical tools in use today
> > for discrediting an opponent's argument without actually addressing it.
> 
> What? Really? You mean the truth doesn't lie in the middle between
> evolution and creationism?

Well, you jest, but actually Intelligent Design is usually presented as
a false compromise between the "extremes" of evolution and creationism.
If you listen to it's proponents, the rhetorical device they use to
argue for legitimacy is precisely an argument to moderation.

James

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[James Bottomley]

On Tue, 2013-07-23 at 21:38 -0400, Steven Rostedt wrote:
> On Tue, 2013-07-23 at 18:26 -0700, James Bottomley wrote:
> 
> > I think it's not in the original fallacies because they come from Greek
> > rhetoric and the Greeks believed dialectic: the taking opposite
> > positions and arguing them thoroughly.  It's only with the advent of
> > Western European political systems that we're conditioned to seek
> > compromise without rigorous examination.  This actually makes argument
> > to moderation one of the most effective rhetorical tools in use today
> > for discrediting an opponent's argument without actually addressing it.
> 
> What? Really? You mean the truth doesn't lie in the middle between
> evolution and creationism?

Well, you jest, but actually Intelligent Design is usually presented as
a false compromise between the "extremes" of evolution and creationism.
If you listen to it's proponents, the rhetorical device they use to
argue for legitimacy is precisely an argument to moderation.

James

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Steven Rostedt]

On Wed, 2013-07-24 at 09:23 -0700, James Bottomley wrote:
> On Tue, 2013-07-23 at 21:38 -0400, Steven Rostedt wrote:
> > On Tue, 2013-07-23 at 18:26 -0700, James Bottomley wrote:
> > 
> > > I think it's not in the original fallacies because they come from Greek
> > > rhetoric and the Greeks believed dialectic: the taking opposite
> > > positions and arguing them thoroughly.  It's only with the advent of
> > > Western European political systems that we're conditioned to seek
> > > compromise without rigorous examination.  This actually makes argument
> > > to moderation one of the most effective rhetorical tools in use today
> > > for discrediting an opponent's argument without actually addressing it.
> > 
> > What? Really? You mean the truth doesn't lie in the middle between
> > evolution and creationism?
> 
> Well, you jest, but actually Intelligent Design is usually presented as
> a false compromise between the "extremes" of evolution and creationism.
> If you listen to it's proponents, the rhetorical device they use to
> argue for legitimacy is precisely an argument to moderation.

Exactly, which is why I used that as an example. And also, just to kick
the hornet's nest.

-- Steve

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Steven Rostedt]

On Wed, 2013-07-24 at 09:23 -0700, James Bottomley wrote:
> On Tue, 2013-07-23 at 21:38 -0400, Steven Rostedt wrote:
> > On Tue, 2013-07-23 at 18:26 -0700, James Bottomley wrote:
> > 
> > > I think it's not in the original fallacies because they come from Greek
> > > rhetoric and the Greeks believed dialectic: the taking opposite
> > > positions and arguing them thoroughly.  It's only with the advent of
> > > Western European political systems that we're conditioned to seek
> > > compromise without rigorous examination.  This actually makes argument
> > > to moderation one of the most effective rhetorical tools in use today
> > > for discrediting an opponent's argument without actually addressing it.
> > 
> > What? Really? You mean the truth doesn't lie in the middle between
> > evolution and creationism?
> 
> Well, you jest, but actually Intelligent Design is usually presented as
> a false compromise between the "extremes" of evolution and creationism.
> If you listen to it's proponents, the rhetorical device they use to
> argue for legitimacy is precisely an argument to moderation.

Exactly, which is why I used that as an example. And also, just to kick
the hornet's nest.

-- Steve

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Felipe Contreras]

On Wed, Jul 24, 2013 at 3:57 AM, Daniel Phillips
<d.phillips@partner.samsung.com> wrote:
> On 07/24/2013 12:51 AM, Felipe Contreras wrote:
>> Your mistaken fallacy seems to be that you think one can *always* be
>> both A (open and honest), and B (polite)...
>
> You are are right, I do think that you can *always* be both open and
> honest, and polite. I do not believe that I am mistaken. And I hope that
> you will come to agree with me in the not too distant future.

What I come to agree is irrelevant. What you _hope_ is not important.
What you _believe_ doesn't really matter.

You've stated what you *think*, that barely has any value in the
discussion, but all right, you've done so already... duly noted.

Moving on. What can be asserted without evidence can be dismissed
without evidence.

-- 
Felipe Contreras

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Felipe Contreras]

On Wed, Jul 24, 2013 at 3:57 AM, Daniel Phillips
<d.phillips@partner.samsung.com> wrote:
> On 07/24/2013 12:51 AM, Felipe Contreras wrote:
>> Your mistaken fallacy seems to be that you think one can *always* be
>> both A (open and honest), and B (polite)...
>
> You are are right, I do think that you can *always* be both open and
> honest, and polite. I do not believe that I am mistaken. And I hope that
> you will come to agree with me in the not too distant future.

What I come to agree is irrelevant. What you _hope_ is not important.
What you _believe_ doesn't really matter.

You've stated what you *think*, that barely has any value in the
discussion, but all right, you've done so already... duly noted.

Moving on. What can be asserted without evidence can be dismissed
without evidence.

-- 
Felipe Contreras

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Willy Tarreau]

On Thu, Jul 25, 2013 at 09:00:37AM -0500, Felipe Contreras wrote:
> Moving on. What can be asserted without evidence can be dismissed
> without evidence.

Guys, could we please stop this endless boring thread ?

Thank you.
Willy

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Willy Tarreau]

On Thu, Jul 25, 2013 at 09:00:37AM -0500, Felipe Contreras wrote:
> Moving on. What can be asserted without evidence can be dismissed
> without evidence.

Guys, could we please stop this endless boring thread ?

Thank you.
Willy

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Steven Rostedt]

On Thu, 2013-07-25 at 16:33 +0200, Willy Tarreau wrote:

> Guys, could we please stop this endless boring thread ?

Just do what I did and kill it with a /dev/null filter.

But wait! How did I see this email? Oh shit! It's come back from the
dead!!!!

-- Steve

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Steven Rostedt]

On Thu, 2013-07-25 at 16:33 +0200, Willy Tarreau wrote:

> Guys, could we please stop this endless boring thread ?

Just do what I did and kill it with a /dev/null filter.

But wait! How did I see this email? Oh shit! It's come back from the
dead!!!!

-- Steve

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Daniel Phillips]

On 07/25/2013 02:34 PM, Willy Tarreau wrote:
> Guys, could we please stop this endless boring thread ?

Willy, I believe we are on the same side of the civility debate, but I 
somehow got the feeling that you just characterized my comment re "open 
and honest" as "endless and boring".

I agree that the attempt to divert the intent of my comment into a 
farcical debate on debating was not worth the internet bytes it was 
printed on. In fact, that nicely demonstrates one class of technique 
commonly used on lkml to silence criticism, and is worth studying from 
that viewpoint. That sort of diverting should end, particularly in 
regards to the topic at hand.

Regards,

Daniel

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Daniel Phillips]

On 07/25/2013 02:34 PM, Willy Tarreau wrote:
> Guys, could we please stop this endless boring thread ?

Willy, I believe we are on the same side of the civility debate, but I 
somehow got the feeling that you just characterized my comment re "open 
and honest" as "endless and boring".

I agree that the attempt to divert the intent of my comment into a 
farcical debate on debating was not worth the internet bytes it was 
printed on. In fact, that nicely demonstrates one class of technique 
commonly used on lkml to silence criticism, and is worth studying from 
that viewpoint. That sort of diverting should end, particularly in 
regards to the topic at hand.

Regards,

Daniel

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Willy Tarreau]

On Thu, Jul 25, 2013 at 10:51:21PM +0000, Daniel Phillips wrote:
> On 07/25/2013 02:34 PM, Willy Tarreau wrote:
> > Guys, could we please stop this endless boring thread ?
> 
> Willy, I believe we are on the same side of the civility debate, but I 
> somehow got the feeling that you just characterized my comment re "open 
> and honest" as "endless and boring".
> 
> I agree that the attempt to divert the intent of my comment into a 
> farcical debate on debating was not worth the internet bytes it was 
> printed on. In fact, that nicely demonstrates one class of technique 
> commonly used on lkml to silence criticism, and is worth studying from 
> that viewpoint. That sort of diverting should end, particularly in 
> regards to the topic at hand.

Daniel, the thread has long diverted and has become a philosophical
debate. I'm still in CC since almost the beginning because I dared to
respond to the *original* discussion (on the subject of how to better
tag commits for stable), conscious of the risk I was taking. I've long
stopped reading this and am still getting these e-mails which remind
me some old tv shows I could occasionally discover when I was a kid,
with old daddies with long hair discussing whether writing with a hand
in the pocket is better for health than brushing your hair with a
plastic brush or not...

So I have no problem stating it here : no, this thread doesn't interest
me anymore. Only the few first exchanges did (those on the workflow of
commits).

I could humbly ask to be removed from the CC list, but since -stable
is CCed as well I'll still receive these discussions in my mailbox. And
given that I'm not the only one to find this one boring, I believe it
is not a selfish request from me to kindly ask this thing to stop. After
all, 2 or 3 persons sending off-topic e-mails to 10, 20, or even 50k
subscribers on a development list might look inadequate to some readers.

Thus, I think it would be *polite* from people who entertain this thread
while smoking I-don't-know-what, to agree that there will always be some
areas where they disagree, that they shake their respective hands and
silently quit the scene so that we can turn off the lights and all go to
bed.

Thanks for your understanding,
Willy

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Willy Tarreau]

On Thu, Jul 25, 2013 at 10:51:21PM +0000, Daniel Phillips wrote:
> On 07/25/2013 02:34 PM, Willy Tarreau wrote:
> > Guys, could we please stop this endless boring thread ?
> 
> Willy, I believe we are on the same side of the civility debate, but I 
> somehow got the feeling that you just characterized my comment re "open 
> and honest" as "endless and boring".
> 
> I agree that the attempt to divert the intent of my comment into a 
> farcical debate on debating was not worth the internet bytes it was 
> printed on. In fact, that nicely demonstrates one class of technique 
> commonly used on lkml to silence criticism, and is worth studying from 
> that viewpoint. That sort of diverting should end, particularly in 
> regards to the topic at hand.

Daniel, the thread has long diverted and has become a philosophical
debate. I'm still in CC since almost the beginning because I dared to
respond to the *original* discussion (on the subject of how to better
tag commits for stable), conscious of the risk I was taking. I've long
stopped reading this and am still getting these e-mails which remind
me some old tv shows I could occasionally discover when I was a kid,
with old daddies with long hair discussing whether writing with a hand
in the pocket is better for health than brushing your hair with a
plastic brush or not...

So I have no problem stating it here : no, this thread doesn't interest
me anymore. Only the few first exchanges did (those on the workflow of
commits).

I could humbly ask to be removed from the CC list, but since -stable
is CCed as well I'll still receive these discussions in my mailbox. And
given that I'm not the only one to find this one boring, I believe it
is not a selfish request from me to kindly ask this thing to stop. After
all, 2 or 3 persons sending off-topic e-mails to 10, 20, or even 50k
subscribers on a development list might look inadequate to some readers.

Thus, I think it would be *polite* from people who entertain this thread
while smoking I-don't-know-what, to agree that there will always be some
areas where they disagree, that they shake their respective hands and
silently quit the scene so that we can turn off the lights and all go to
bed.

Thanks for your understanding,
Willy

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Daniel Phillips]

Hi Willy,

I understand completely. I don't blame you. Filter the thread. Done.

I am not tired of the subject, quite the contrary. Please do not speak 
for me in that regard. After many years of wandering in the toxic 
wasteland, finally some actual progress.

Regards,

Daniel

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Daniel Phillips]

Hi Willy,

I understand completely. I don't blame you. Filter the thread. Done.

I am not tired of the subject, quite the contrary. Please do not speak 
for me in that regard. After many years of wandering in the toxic 
wasteland, finally some actual progress.

Regards,

Daniel

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Willy Tarreau]

On Thu, Jul 25, 2013 at 11:44:50PM +0000, Daniel Phillips wrote:
> Hi Willy,
> 
> I understand completely. I don't blame you. Filter the thread. Done.

So because people speak loudly at night below my window in summer, I
have to close the window and install a fan to get some air ? And all
the neighbours have to do the same ? Sorry, there are places for this
I'd rather politely ask them to go to these places. And anyway it's
much easier for me to write rules to block addresses than subjects,
so if I am bored enough to write a rule it will target the participants.

Keep your discussion on LKML if you want it to be public, it's even
on the subject and nobody will care because nobody has it in his main
mailbox anymore. But please remove the other people that were left CCed
and who don't participate to the thread, as well as the ksummit and
stable lists that are for completely different purposes.

Thanks,
Willy

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Willy Tarreau]

On Thu, Jul 25, 2013 at 11:44:50PM +0000, Daniel Phillips wrote:
> Hi Willy,
> 
> I understand completely. I don't blame you. Filter the thread. Done.

So because people speak loudly at night below my window in summer, I
have to close the window and install a fan to get some air ? And all
the neighbours have to do the same ? Sorry, there are places for this
I'd rather politely ask them to go to these places. And anyway it's
much easier for me to write rules to block addresses than subjects,
so if I am bored enough to write a rule it will target the participants.

Keep your discussion on LKML if you want it to be public, it's even
on the subject and nobody will care because nobody has it in his main
mailbox anymore. But please remove the other people that were left CCed
and who don't participate to the thread, as well as the ksummit and
stable lists that are for completely different purposes.

Thanks,
Willy

Re: [ 00/19] 3.10.1-stable review

[Regina Obe]

Mike,

I do want to partially apologize to Sarah for my first email.  That
was really much tongue in cheek to express what happens when things
get too polite
and professional and hope she wasn't too offended.  I saw Sarah's last post
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg471360.html

and see she's changed her tune a bit which is a lot more agreeable to
me and I suspect others.

However I still thinks she's a little bit too pendantic to the point
of being really annoying and seeming like she's memorized the book of
conduct quoting things like  "

The book "No Assholes Rule" cites research that shows only 1% of
subordinates bully their superiors"

and is ready to throw it in peoples faces if they infringe on the rules.
Those rules are way too long to follow.  Why can't you guys just trust
your insticts and if you are relaly worried about Linus -- just make
it a rule "If anybody thinks X is acting as a jerk at this very moment
-- call it out"

Honestly do yo guys even have time to read 20 pages of what is and
ISN'T and insult. I also suspect the public viewers aren't going to be
looking up at an Org Chart "Hmm let me check if Linus is allowed to
insult this guy :) "

When you are at the party since she's probably going to miss this note
because its on a dead thread if you could convey my sentiments.

Thanks,
Regina

RE: [ 00/19] 3.10.1-stable review

[Regina Obe]

> Which means you're likely not invited to the annual mud-wrestling and toga
party where this topic has been scheduled for further discussion.
> This thread and its offspring have been declared dead on LKML, we're in
kernel development mode again.

> -Mike

That's okay.  Just wanted to express my comments.

Regina

Re: [ 00/19] 3.10.1-stable review

[Mike Galbraith]

On Mon, 2013-07-22 at 21:42 -0400, Regina Obe wrote:

> Linus,
> I want to start off by saying, though I'm mostly a windows developer,

Which means you're likely not invited to the annual mud-wrestling and
toga party where this topic has been scheduled for further discussion.
This thread and its offspring have been declared dead on LKML, we're in
kernel development mode again.

-Mike

Re: [ 00/19] 3.10.1-stable review

[Regina Obe]

I wanted to take Sarah up on her offer to pay my respects for the
great work she is doing to bring civility to the LKLM community
as detailed in http://marc.info/?l=linux-kernel&m=137390362508794

Linus,
I want to start off by saying, though I'm mostly a windows developer,
I've gained a whole new level of appreciation for you, with the very
professional
way you have handled Sarah's pleas for civility and professionalism. I
hope you don't think of "professionalism" and "civility" as dirty
words, because I certainly did not mean it that way.
I have tried to express my own feelings in the most professional and
civil way I could
muster in this article
http://www.postgresonline.com/journal/archives/311-In-defense-of-being-blunt-and-to-the-point.html
.

I want to first say that while Sarah does not speak for me, and I
suspect she does not speak for all minorities, females, and the poor
down-trodden developers
in your ranks that have had their feelings torn apart by your less
than kind words, I do still appreciate her great efforts to bring
civility to LKML. You go girl, Sarah -- keep fighting the good fight,
we are with you - both men and women. I do hope your efforts do not
make it difficult for women to distinguish criticism from platitudes.

Perhaps some day, Sarah, your dream will come true and you can be a
top tier committer as you stated in your moving up the career rank
comment.
http://sarah.thesharps.us/2013/07/15/no-more-verbal-abuse/#comments

You won't even have to work for it, because Linus will be so scared of you
he'll just hand it over to you and accept any patch you give him.

Please don't take my above statement as an accusation that that is
what you are doing.  That is not at all what I meant.  I just meant to
say that if you wanted to exercise that
option, you are in a good position to. Consider it just my suggested
career advice just like the wonderful career advice you have given to
other women in your blog
http://sarah.thesharps.us/2013/06/23/dont-be-a-jerk/ .

I do have one final request. If you do succeed in your quest for
civility and professionalism,  please do try to keep the office
politics where they belong, in the office.
I'd still like to think there is still some semblance of openness
after you are done with your restructuring.

I want to thank you one more time for the great work you have done
bringing this GREAT INJUSTICE to our attention. I certainly would not
have discovered it without all the great accolades you have won for
this from both men and women
http://www.wired.co.uk/news/archive/2013-07/22/sarah-sharp . You must
be some kind of wonder woman. I am so very very appreciative that
there is a woman out there willing to stand up to Linus verbal abuse
and fight for those who are too afraid to stand up for themselves.

You are just SO *fucking* cool.

YOU GO GIRL SARAH.

Thanks,
Regina Obe

Re: [ 00/19] 3.10.1-stable review

[George Spelvin]

> If you can point me to a single instance of Linus "abusing" someone
> who is not one of his trusted persons, who really should be able to
> deal with that, or someone who did not provoke him to go into rant
> mode, then I'm all on your side.

Well, the one that comes to mind is Alan Cox and the TTY driver in
2009.

And I still have to agree with his point about Linus's more absolute
pronouncements on user-space regressions: taken literally, they mean
that breaking rootkits is not okay.

Here's the thread if anyonw would like to judge "who started it":

http://marc.info/?t=124870111900001


That said, I strongly agree with this point:
> Linus simply has to trusts his top level maintainers, because he
> cannot review, audit and check 10k patches which flow into his tree
> every merge window himself.
>
> So if he finds out that someone who has his ultimate trust sends him a
> pile of crap, he tells that person in his own unmisunderstandable way
> that he's not amused.

Re: [ 00/19] 3.10.1-stable review

[Willy Tarreau]

On Mon, Jul 15, 2013 at 12:12:04PM +0800, Li Zefan wrote:
> > It is *my* conception of the stable branch, but I think that many people
> > have different expectations about what should be merged or not. For example
> > in old LTS branches, I used to merge what was relevant for servers only,
> 
> We have lots of embeded systems running 2.6.32 kernel. And we encountered
> a critical bug, and we had to backported some patches which are not bug fixes
> to prevent the bug from happening.

If these patches are not too numerous nor too big, and that what they fix is
really obvious, it could be useful to discuss their merging on the stable list,
especially if you believe the bug is not specific to your environment.

Thanks,
Willy

Re: [ 00/19] 3.10.1-stable review

[Li Zefan]

> It is *my* conception of the stable branch, but I think that many people
> have different expectations about what should be merged or not. For example
> in old LTS branches, I used to merge what was relevant for servers only,

We have lots of embeded systems running 2.6.32 kernel. And we encountered
a critical bug, and we had to backported some patches which are not bug fixes
to prevent the bug from happening.

> because I saw no reason why an old kernel would be used on a laptop (eg:
> 2.4). So I always skipped wifi, alsa, drm, etc... With 2.6.32, the Debian
> kernel guys provided me with a lot of fixes in these areas, explaining
> that these fixes addressed issues that their users were facing, and they
> were perfectly right. It's just that I didn't expect this at all.

Re: [ 00/19] 3.10.1-stable review

[Benjamin Herrenschmidt]

On Sun, 2013-07-14 at 18:40 -0700, Linus Torvalds wrote:
> Not before it's been in the distro, no. Something like a PCI change
> *definitely* should never be marked for stable, unless it causes
> crashes or is a _new_ regression that causes dead machines.
> 
> Because the likelihood that that 4-5 line "obvious" change breaks
> things is pretty high. It needs testing elsewhere - on the machines
> that weren't broken - in a big way first.
> 
> And don't bother talking about "obvious fix". Especially not when it
> comes to the PCI code.

PCI resource allocation code for sure. A bug specific to the hotplug
code path not so ... (for example, a too short reset delay or shit like
that). I agree with you overall but there's still a judgement call
happening at some point I assume and we get at least *some* flexibility
as maintainers as to what we want going there or not right ? :-)

Cheers,
Ben.

Re: [ 00/19] 3.10.1-stable review

[Linus Torvalds]

On Sun, Jul 14, 2013 at 4:52 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
>
> So if I read this (and stable_kernel_rules.txt) correctly, that means that
> for example, let's say, we find in RHEL66 or SLES42 (possibly following
> a user report), for example, that PCI hotplug is broken with some category
> of devices on some machines.
>
> We do a fix, it's roughtly 4 or 5 lines, pretty self contained. We get it
> into the distro.
>
> That still doesn't qualify for stable right ?

Not before it's been in the distro, no. Something like a PCI change
*definitely* should never be marked for stable, unless it causes
crashes or is a _new_ regression that causes dead machines.

Because the likelihood that that 4-5 line "obvious" change breaks
things is pretty high. It needs testing elsewhere - on the machines
that weren't broken - in a big way first.

And don't bother talking about "obvious fix". Especially not when it
comes to the PCI code.

                 Linus

Re: [ 00/19] 3.10.1-stable review

[Benjamin Herrenschmidt]

On Fri, 2013-07-12 at 10:50 -0700, Linus Torvalds wrote:
> You cut out the important part:
> 
>  - It must fix a problem that causes a build error (but not for things
>    marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
>    security issue, or some "oh, that's not good" issue.  In short, something
>    critical.
> 
> That list is not a "or" list, it's an "and" list - it needs to follow
> *all* the rules. The exception is the "New device IDs and quirks are
> also accepted", which maybe should be made more clearly separate.

So if I read this (and stable_kernel_rules.txt) correctly, that means that
for example, let's say, we find in RHEL66 or SLES42 (possibly following
a user report), for example, that PCI hotplug is broken with some category
of devices on some machines.

We do a fix, it's roughtly 4 or 5 lines, pretty self contained. We get it
into the distro.

That still doesn't qualify for stable right ? We have to start shooting at
every distro around separately or wait for users of those other distros
to also hit it ?

Where is the line when something "Doesn't work" (without crashing/oops'ing or
being a security issue) ?

My personal line so far has been to take it and send it to -stable if the
patch is simple enough and self contained (little risk of side effects).

But I can stop if that's indeed the accepted rule.

Cheers,
Ben.

Re: [ 00/19] 3.10.1-stable review

[Benjamin Herrenschmidt]

On Thu, 2013-07-11 at 15:01 -0700, Greg Kroah-Hartman wrote:
> s is the start of the stable review cycle for the 3.10.1 release.
> There are 19 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied,
> please
> let me know.
> 
> Responses should be made by Sat Jul 13 21:45:35 UTC 2013.
> Anything received after that time might be too late.

And you expect that we all have time to dig that out from lkml in 1
day ? You have a rant about powerpc and don't CC me ? :-)

This one is really important/urgent:

74251fe21bfa9310ddba9e0436d1fcf389e602ee
"powerpc/powernv: Fix iommu initialization again"

Cheers,
Ben.

Re: [ 00/19] 3.10.1-stable review

[Benjamin Herrenschmidt]

On Thu, 2013-07-11 at 15:44 -0700, Greg Kroah-Hartman wrote:
> > And the later in -rc we are, the more reluctant some people seem to be
> > at sending stuff. Which, for slowing things down as we go through -rc is great,
> > but not so much when people stop sending _everything_ and start thinking
> > "I'll just get it in stable in a few weeks".
> 
> The 20 powerpc patches are proof of that.  I'm amost considering just
> not applying them at all, as obviously they weren't all that important.

Can you stop about powerpc for a minute Greg ? It's becoming tiring.... When it's
not this (seriously ? We are by FAR not the worst managed architecture around here
but you seem to pick on any opportunity, public medium, etc... to trash us for
whatever reason, time to find another axe to grind really).

Also look at the damn history. We rarely had that much stuff going back. You know
3.10 is special and you probably know why, and I've mentioned already that a lot
of that stuff you are complaining about affects HW that people do NOT have presently
access to outside of IBM.

Please, go play another violin.

Ben.

Re: [ 00/19] 3.10.1-stable review

[Benjamin Herrenschmidt]

On Thu, 2013-07-11 at 18:14 -0400, Josh Boyer wrote:
>    Why are subsystem maintainers holding on to fixes that are
> >   _supposedly_ affecting all users?  I mean, 21 powerpc core changes
> >   that I don't see until a -rc1 merge?  It's as if developers don't
> >   expect people to use a .0 release and are relying on me to get the
> >   fixes they have burried in their trees out to users.  

Let me guess, a lot of these are Power8 fixes ... This is a bit special
this time around... we introduced some of the support in 3.9 and added a
bunch in 3.10. We found bugs, it's brand new HW (not even final yet),
and nobody out there has access to it nor will for a little while
longer, so indeed nobody is going to use 3.10.0.

I've been pushing back on a lot of it as a maintainer (which is why a
lot of stuff ended up in 3.10 instead of 3.9), but granted probably not
enough this time around.

It's hard because the guys are getting a LOT of pressure in part because
of distro schedules.

As you are aware (and I mentioned in another email), some enterprise
distros impose a very specific schedule for stuff to go upstream, and if
that misses, well .... you are out of the game for years or lots of $ to
convince them otherwise. Additionally, one of them has brain damaged
rules about preserving kernel ABIs which prevents any significant
addition for the entire lifetime of the distro major release.

This is bad, this should not affect upstream in theory, but in practice
it does because if we don't get into the damn enterprise distro, the
whole exercise is pointless to begin with and we may as well not release
the machines and stop the Linux business altogether.

So I make compromises. I delay some stuff because it's really not ready,
and I take some because it affects things like thread_struct layout
which I know *WILL* break kABI and will be VERY hard to get back to the
distro later, fully expecting that various bits of fixes are going to
eventually trickle later on until it's ready for public consumption.

Ben.

Re: [ 00/19] 3.10.1-stable review

[Benjamin Herrenschmidt]

On Fri, 2013-07-12 at 10:05 -0700, Greg Kroah-Hartman wrote:
> Specific example is, again, the powerpc patches.  Out of 21 patches
> marked for stable that showed up in the -rc1 merge, at least 7 of them
> had _plenty_ of time to get into 3.10.0 as they are weeks, and sometimes
> months, old.  Some of the other ones seem _very_ new, being only days
> old before they hit Linus's tree, which makes me worry about them for
> totally different reasons (i.e. not tested in linux-next at all.)

So for the old ones that's me not actively sending you stuff that has a
CC stable tag when I merge it. I should probably fix that indeed. This
is especially true of (but not exclusively) stuff that I don't apply
myself but merge via somebody else branch.

For the new stuff, this is a combinations of some last minute fuckups
which are pretty specific to 3.10 and for which I'm in part responsible,
and in part due to us basically ramping up testing on Power8 and getting
ready for the next RHEL & SLES at the same time, thus doing more testing
internally.

You'll notice that a lot of that stuff is P8 support so testing in
"next" isn't going to help much since nobody outside of IBM has access
to these guys yet. We are getting the stuff out there due to distro
unrealistic expectations of having upstream code for new machines years
before a release.

Also keep in mind that sometimes, that stuff has been around on
patchwork for a while and got tested by various people, but the patch
got a last minute rev of improved changeset comment or cosmetic polish.

> I can put a "delay" on patches to not hit a stable release for a few
> weeks until they get some testing in Linus's tree, but in reality,
> what's that going to help with?

Depends. In some of the patches I put in for stable, they fix something
that 3.10 broke and the fixes are quite self-contained, waiting makes no
sense.

At some stage I make a judgement call on a given patch, how "obvious"
the fix is (I know they never are completely ... well most of the time),
how invasive it is, what risk it represents outside of the are that it
"fixes". I do mistakes, but generally I am fairly conservative in that
area.

> I guess I can just not apply them at all, tough-love and all that, but
> that just puts an extra burden on the distro kernel maintainers to have
> to go dig up the fixes for their users.

You know how the distro can be about that... especially when they invent
idiotic junk such as kABI which prevents you from fixing things properly
for the sake of [probably illegal] binary drivers, and so on... Distro
seem to enjoy establishing a process that guarantee that an "enterprise
release" is entirely comprise of utter junk (not even talking about all
the in-house untested broken stupid crap they add to their kernels while
at the same time being hard-ass with fixes coming from the vendors).

> Although really, who cares about powerpc anymore :)

That was unfair :-)

Cheers,
Ben.

Re: [ 00/19] 3.10.1-stable review

[Geert Uytterhoeven]

On Sun, Jul 14, 2013 at 7:24 AM, Guenter Roeck <linux@roeck-us.net> wrote:
>> You are confusing the words "real" and "critical" perhaps.  I, and other
>
> A typical classification of bugs might be
>         critical: mission critical, no workaround, must be fixed prior to
>                 customer release
>         severe (high): related to core functionality, must fix, but not
>                 necessarily in first release.
>         moderate (medium): Bugs that do not affect any critical user
>                 functionality; typically has workaround
>         minor (low): Bugs that do not interfere with core functionality
>                 and are just annoyances that may or may not ever be fixed
>         cosmetic: misspellings
>
> Such classifications are widely used in the industry. The term "affecting users"
> might apply to all of those, and even a cosmetic bug is "real".

And typically there's a distinction between severity (how bad is it), and
priority (how soon it should be fixed), wich are not always linearly correlated.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [ 00/19] 3.10.1-stable review

[Guenter Roeck]

On Sat, Jul 13, 2013 at 08:51:28PM -0700, Greg Kroah-Hartman wrote:
> On Sat, Jul 13, 2013 at 10:22:19PM -0400, Theodore Ts'o wrote:
> > On Sat, Jul 13, 2013 at 11:27:17AM -0700, Greg Kroah-Hartman wrote:
> > > Ugh, the conversation has degenerated now into parsing the meaning of
> > > specific words.  This is why lawyers have created whole vocabularies
> > > that are not used by "normal" people.  There's a very good reason why
> > > I'm not a lawyer, and this is one of them...
> > > 
> > > If I change the word "critical" to "real", would that make everyone
> > > happy here?
> > > 
> > > It comes down to the simple fact that for stable kernels I _want_ to
> > > take bugfixes that any user would hit.  In other words, something that a
> > > distro kernel would take.
> > 
> > Yes, but ***Linus*** has said he only wants critical fixes in his tree
> > after -rc4.  It seems pretty clear that what he wants post -rc4 and
> > what you want in the stable tree are different.
> > 
> > You can change the stable_kernel_tree to be "real" bugs, but if Linus
> > is still using "critical" as the standard for mainline post-rc4, then
> > those of us who are maintainers are stuck between a rock and a hard
> > place.
> 
> You are confusing the words "real" and "critical" perhaps.  I, and other

A typical classification of bugs might be
	critical: mission critical, no workaround, must be fixed prior to
		customer release
	severe (high): related to core functionality, must fix, but not
		necessarily in first release.
	moderate (medium): Bugs that do not affect any critical user
		functionality; typically has workaround
	minor (low): Bugs that do not interfere with core functionality
		and are just annoyances that may or may not ever be fixed
	cosmetic: misspellings

Such classifications are widely used in the industry. The term "affecting users"
might apply to all of those, and even a cosmetic bug is "real".

I don't think this is about confusion, but about classification. Clearly we
don't want patches for cosmetic or minor bugs in stable releases, but where
is the cut-off point ? That may be clear for you and some of the maintainers,
but for me and probably many other maintainers, "critical" has a well defined
meaning which neither includes severe nor moderate bugs as per the classification
above.

The term "real" is much more vague and left to interpretation. My cutoff
point would be around "moderate" - it does affect users, but it is not
critical functionality. What is yours ?

Guenter

> large subsystem maintainers, based on how they submit fixes to Linus and
> to stable, view the late -rc portion as time for fixes that affect users
> and other issues like that.  So far, it's worked out pretty well and we
> don't seem to be in disagreement with Linus's view of what is a valid
> late -rc fix based on recent kernel development cycles.
> 
> The issue now is, we have maintainers who aren't sending stuff to Linus
> at all in the late -rc cycle and are relying on me to pick up things
> that are obviously "real" and "critical" fixes after .0 is out for .1
> and .2 to resolve "real" issues.
> 
> You are not one of these people, so I don't understand why you are
> getting upset and think that you somehow need to change how you mark
> stuff for stable.
> 
> The powerpc and iscsi people on the other hand, they need to look out...
> 
> chill out please and go enjoy the rest of the weekend,
> 
> greg k-h
> 

Re: [ 00/19] 3.10.1-stable review

[Greg Kroah-Hartman]

On Sat, Jul 13, 2013 at 10:22:19PM -0400, Theodore Ts'o wrote:
> On Sat, Jul 13, 2013 at 11:27:17AM -0700, Greg Kroah-Hartman wrote:
> > Ugh, the conversation has degenerated now into parsing the meaning of
> > specific words.  This is why lawyers have created whole vocabularies
> > that are not used by "normal" people.  There's a very good reason why
> > I'm not a lawyer, and this is one of them...
> > 
> > If I change the word "critical" to "real", would that make everyone
> > happy here?
> > 
> > It comes down to the simple fact that for stable kernels I _want_ to
> > take bugfixes that any user would hit.  In other words, something that a
> > distro kernel would take.
> 
> Yes, but ***Linus*** has said he only wants critical fixes in his tree
> after -rc4.  It seems pretty clear that what he wants post -rc4 and
> what you want in the stable tree are different.
> 
> You can change the stable_kernel_tree to be "real" bugs, but if Linus
> is still using "critical" as the standard for mainline post-rc4, then
> those of us who are maintainers are stuck between a rock and a hard
> place.

You are confusing the words "real" and "critical" perhaps.  I, and other
large subsystem maintainers, based on how they submit fixes to Linus and
to stable, view the late -rc portion as time for fixes that affect users
and other issues like that.  So far, it's worked out pretty well and we
don't seem to be in disagreement with Linus's view of what is a valid
late -rc fix based on recent kernel development cycles.

The issue now is, we have maintainers who aren't sending stuff to Linus
at all in the late -rc cycle and are relying on me to pick up things
that are obviously "real" and "critical" fixes after .0 is out for .1
and .2 to resolve "real" issues.

You are not one of these people, so I don't understand why you are
getting upset and think that you somehow need to change how you mark
stuff for stable.

The powerpc and iscsi people on the other hand, they need to look out...

chill out please and go enjoy the rest of the weekend,

greg k-h

Re: [ 00/19] 3.10.1-stable review

[Theodore Ts'o]

On Sat, Jul 13, 2013 at 11:27:17AM -0700, Greg Kroah-Hartman wrote:
> Ugh, the conversation has degenerated now into parsing the meaning of
> specific words.  This is why lawyers have created whole vocabularies
> that are not used by "normal" people.  There's a very good reason why
> I'm not a lawyer, and this is one of them...
> 
> If I change the word "critical" to "real", would that make everyone
> happy here?
> 
> It comes down to the simple fact that for stable kernels I _want_ to
> take bugfixes that any user would hit.  In other words, something that a
> distro kernel would take.

Yes, but ***Linus*** has said he only wants critical fixes in his tree
after -rc4.  It seems pretty clear that what he wants post -rc4 and
what you want in the stable tree are different.

You can change the stable_kernel_tree to be "real" bugs, but if Linus
is still using "critical" as the standard for mainline post-rc4, then
those of us who are maintainers are stuck between a rock and a hard
place.

So it's not a matter of maintainers trying to lawyer the meaning of
words, but that you and Linus have different criteria of what you feel
should be sent to mainline after -rc4.  And sorry, it's Linus's
kernel, so I'm going to follow what appears to be Linus's criteria.


If you and Linus can't come up with an the same set of criteria, all I
can do is to not send non-regression/non-critical, fixes post -rc4 (so
Linus doesn't yell at me), and not mark non-critical bug fixes (even
if distro kernels would want them) for stable (so you don't yell at me
for not pushing them to Linus).  What I'll probably do is mark them
with "Fixes: v3.x" tag, and then I'll have to create my own scripts to
send patches to stable@vger.kernel.org a week or two after Linus has
released the 3.y.0 kernel.

Regards,

					- Ted

Re: [ 00/19] 3.10.1-stable review

[Greg Kroah-Hartman]

On Sat, Jul 13, 2013 at 07:42:11AM -0400, Theodore Ts'o wrote:
> On Fri, Jul 12, 2013 at 11:48:01PM -0700, Greg Kroah-Hartman wrote:
> > > It's the difference between "this is a fix" and "please backport this
> > > fix into stable". As we aid in this thread, cc:stable is a bit too much
> > > automatic and sometimes not appropriate (not important enough fixes).
> > 
> > No, I've never said that.
> 
> You've not said this, but Linus has.  Linus has pointed at the
> following words which are in stable_kernel_rules:
> 
>  - It must fix a problem that causes a build error (but not for things
>    marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
>    security issue, or some "oh, that's not good" issue.  In short, something
>    critical.                                             ^^^^^^^^^^^^^^^^^^^
>    ^^^^^^^^

Ugh, the conversation has degenerated now into parsing the meaning of
specific words.  This is why lawyers have created whole vocabularies
that are not used by "normal" people.  There's a very good reason why
I'm not a lawyer, and this is one of them...

If I change the word "critical" to "real", would that make everyone
happy here?

It comes down to the simple fact that for stable kernels I _want_ to
take bugfixes that any user would hit.  In other words, something that a
distro kernel would take.

And, I'll throw up the famous "I know it when I see it", definition of
what a valid fix is, to keep people from "word parsing" the exact way to
write it all down.

It's a grey area, which is good, let's keep it that way.

And again, that's not the real problem here.  The real problem is that
people are keeping valid "fixes" out of the .0 kernel for some odd
reason.

So here's what I'm going to do.  I'm going to go through all of my
pending stable patches in the next few days, discarding anything that
remotely "hints"[1] that it should have been pushed to Linus for .0.

Then I'll notify those maintainers, and make them resend the patches,
and explain _why_ they held off sending them, if they really want them
in the stable releases.

That should hopefully start to notify maintainers that they need to step
up and send stuff to Linus earlier, or they can justify why they didn't
send them at the time (which is fine, I know I think I have valid
reasons for why I didn't send some of my -stable patches in for the .0
release.)

I'll start digging through linux-next about -rc4 timeframe and watch for
stable tags to show up, and start pestering people about why they are
there and not in Linus's tree.

And then let's see what happens for 3.11.0, and the 3.12-rc1 merge
window.  If nothing's changed by then compared to this flood we got for
3.11-rc1, then we can revisit it then.

Yes, this is going to require more work on my behalf for the next few
months, but what else was I going to do with my summer, actually enjoy
the weather?...

Sound ok with everyone?

greg k-h

[1] A big hint is the date of the patch being a month or so before .0
    was released.  I'll point to the powerpc mess as an example of
    that...

Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Sat, 2013-07-13 at 11:10 -0400, Dave Jones wrote:
> On Sat, Jul 13, 2013 at 07:11:29AM -0400, Steven Rostedt wrote:
> 
>  > > Users expect vanilla .0 releases usable as production systems, to
>  > > be updated (meaning, no new features, just stabilizing) with the
>  > > corresponding -stable series.
>  > 
>  > This really is a case by case basis. An unprivileged user exploit
>  > requires a box that lets other users than the owner of the box to log
>  > in. Most users of .0 releases do not do this.
> 
> local exploits aren't just a problem for multi-user machines.
> An attacker who can own your firefox process, can now potentially
> escalate to root.  (Ok, most exploits are just crashing the box,
> but how many times have we been proven wrong in the past when we
> thought something was just a DoS, and someone smarter has found
> a way to turn it into a root-hole?)

Of course I don't want to lower the importance of such a fix. But making
sure the fix works and not rushed out is important too. It really is a
case by case basis. Some bugs should get out to mainline and stable
quickly, but a lot of them should also be verified to work before
rushing to get them out the door. And verification does take a bit of
time. The last thing we want a fix to do is to create a bug that could
potentially be worse than the one being fixed.

-- Steve

Re: [ 00/19] 3.10.1-stable review

[Dave Jones]

On Sat, Jul 13, 2013 at 07:11:29AM -0400, Steven Rostedt wrote:

 > > Users expect vanilla .0 releases usable as production systems, to
 > > be updated (meaning, no new features, just stabilizing) with the
 > > corresponding -stable series.
 > 
 > This really is a case by case basis. An unprivileged user exploit
 > requires a box that lets other users than the owner of the box to log
 > in. Most users of .0 releases do not do this.

local exploits aren't just a problem for multi-user machines.
An attacker who can own your firefox process, can now potentially
escalate to root.  (Ok, most exploits are just crashing the box,
but how many times have we been proven wrong in the past when we
thought something was just a DoS, and someone smarter has found
a way to turn it into a root-hole?)

	Dave

Re: [ 00/19] 3.10.1-stable review

[Theodore Ts'o]

On Fri, Jul 12, 2013 at 11:48:01PM -0700, Greg Kroah-Hartman wrote:
> > It's the difference between "this is a fix" and "please backport this
> > fix into stable". As we aid in this thread, cc:stable is a bit too much
> > automatic and sometimes not appropriate (not important enough fixes).
> 
> No, I've never said that.

You've not said this, but Linus has.  Linus has pointed at the
following words which are in stable_kernel_rules:

 - It must fix a problem that causes a build error (but not for things
   marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
   security issue, or some "oh, that's not good" issue.  In short, something
   critical.                                             ^^^^^^^^^^^^^^^^^^^
   ^^^^^^^^

> I _want_ fixes in stable trees, as they are being done to, obviously,
> fix problems.  So does Linus, why wouldn't a fix for something that is
> an issue for someone _not_ go into his tree after -rc4?

Linus has said he doesn't want fixes that aren't CRITICAL after -rc4.

So the problem is there's apparently a discrepancy between your
standards for when a patch should hit stable, and Linus's criteria for
post-rc4 inclusion.

Originally, this boundary for "nothing but regressions and critical
fixes" was -rc3 at the latest, which is why I've sat on fixes after
-rc2 has been released.  But since you've wanted these fixes, I would
mark them stable, with the assumption that by the time I've completed
all of the regression tests before the merge window, it would be fine
for stable.

Here's another real-life situation which is happening right now.  It's
almost -rc1, and I've believe that discovered a potential ext4 bug
fix.  It fixes a long-standing xfstest failure, that we've been trying
to track down for several releases.  This is the sort of thing that
stable enterprise distro's would want (eventually), since otherwise
their help desks would be tearing their hair out with a
hard-to-reproduce and hard-to-root-cause bug report from the field.
I'll probably want to push out this fix to Linus, assuming it passes
all of my regression tests --- especially since Linus has said he'll
now take bug-fixes before -rc4.

But is this the sort of thing that we would want in stable right away?
I was thinking that perhaps the right thing to do was to mark it with
a "Fixes: v3.8" (indicating that eventually this may want to be sent
to all stable kernel releases v3.8+), but perhaps it shouldn't be
automatically scooped up for stable, at least until a week or two
after 3.11 comes out and we're sure that the bug fix doesn't introduce
some other regression.

I'll note that technically this fix might not meet the "something
critical" test in stable_kernel_rules, since it only occurs under
extreme memory pressure, and it's otherwise extraordinarily hard to
reproduce (but this is why it's extraordinarily expensive for
enterprise distros to root cause these sorts of problem when they are
reported from the field).

> I _should_ be seeing more patches marked for stable showing up after
> -rc3 then for -rc1.  As it is, I think there's something wrong with
> maintainers relying on me to do their work for them too much, and it's
> finally pushed me to start complaining and pushing back.

How about this?  If patches marked for stable show up after 3.11-rc2,
or 3.11-rc3, could they not get automatically scooped up until a week
after 3.11 comes out?  If a post-rc2 patch shows up in 3.10.x before
3.11 comes out, and it is not a __critical__ bug fix, I would be
really uncomfortable about accidentally introducing a regression into
the stable kernel tree --- at least for a subsystem like ext4, where a
regression might lead to data corruption (which generally makes users
a lot more cranky than a bug in some random graphics driver which just
causes their system to reboot.)

If it's critical, I'll explicitly send it to stable@vger.kernel.org;
but if it's not critical, I really would like more soak time in
mainline before it gets picked up for stable.  If you don't think this
is appropriate for all subsystems, maybe it could be a per-subsystem
policy --- but I really think this is a good idea for everyone.

Regards,

						- Ted

P.S.  Maybe this is a grey area that you're not worried about, and
you're actually getting more cranky about people labelling whitespace
fixes with stable@vger.kernel.org.  My personal policy is those sorts
of changes should *** NEVER *** be sent to the stable kernel series,
regardless of when they hit either my tree or mainline....

Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Sat, 2013-07-13 at 02:47 +0200, Jochen Striepe wrote:
> 	Hello,
> 
> On Fri, Jul 12, 2013 at 04:28:20PM -0400, Steven Rostedt wrote:
> > I would suspect that machines that allow unprivileged users would be
> > running distro kernels, and not the latest release from Linus, and thus
> > even a bug that "can allow an unprivileged user to crash the kernel" may
> > still be able to sit around for a month before being submitted.
> > 
> > This wouldn't be the case if the bug was in older kernels that are being
> > used.
> 
> On the one hand, you seem to want users with any kind of production
> systems to use distro kernels. On the other hand, developers want
> a broad testing base, with vanilla kernels (or better, rc) as early
> as possible. You cannot get both at the same time, some kinds of bugs
> just appear on production systems.
> 
> Users expect vanilla .0 releases usable as production systems, to
> be updated (meaning, no new features, just stabilizing) with the
> corresponding -stable series.

This really is a case by case basis. An unprivileged user exploit
requires a box that lets other users than the owner of the box to log
in. Most users of .0 releases do not do this.

But this isn't the point anyway. The point I was making is not to let
the fix be worse than the bug it fixes. What happens if the fix to an
unprivileged user exploit inadvertently opens an off by one bug that can
be exploited by external users?

It comes down to each bug itself. If the fix is trivial and fixes a
critical bug, it should be pushed rather quickly to mainline. But if the
fix requires a redesign of some code, it would require more time.
Luckily, most security bugs are quick fixes, and don't need a redesign
of the code.

-- Steve

Re: [ 00/19] 3.10.1-stable review

[Willy Tarreau]

On Fri, Jul 12, 2013 at 11:48:01PM -0700, Greg Kroah-Hartman wrote:
> > > And if something "fixes" an issue, then I want it in stable, just like
> > > Linus wants that in his tree.
> > 
> > It's the difference between "this is a fix" and "please backport this
> > fix into stable". As we aid in this thread, cc:stable is a bit too much
> > automatic and sometimes not appropriate (not important enough fixes).
> 
> No, I've never said that.
> 
> I _want_ fixes in stable trees, as they are being done to, obviously,
> fix problems.  So does Linus, why wouldn't a fix for something that is
> an issue for someone _not_ go into his tree after -rc4?
> 
> Ok, for some issues, they need some time to "bake" I can understand, but
> that's the exception not the rule at all.

I do think that most of the fixes that are sent to stable should bake a
little bit more, especially the ones that are not considered critical
(and that according to Linus should not be in stable). After all that's
what Davem does and there are probably less reverts in the stable net
tree than in others.

> If a distro would pick a patch up to solve a problem for a user, and
> that patch is in Linus's tree, there's almost no reason that shouldn't
> also be in the stable trees.

It is *my* conception of the stable branch, but I think that many people
have different expectations about what should be merged or not. For example
in old LTS branches, I used to merge what was relevant for servers only,
because I saw no reason why an old kernel would be used on a laptop (eg:
2.4). So I always skipped wifi, alsa, drm, etc... With 2.6.32, the Debian
kernel guys provided me with a lot of fixes in these areas, explaining
that these fixes addressed issues that their users were facing, and they
were perfectly right. It's just that I didn't expect this at all.

> My issue is that people are trying to get me to take stuff that is _not_
> fixes (i.e. build errors that are impossible to hit, or \n additions to
> debugging kernel messages, or pseudo-optimizations of functions).

But you see, maybe the '\n' additions are important to a specific development
team who relies on this all the day for their work. Importance is a relative
thing by nature. But I get your point anyway. Such low general importances
fixes could be marked "fix" without being marked "cc:stable" so that users
can later explicitly ask for their inclusion if they're concerned. That is
the way we know the problem affects some users. A few tens of the fixes that
went into 2.6.32.61 were requested by users, and I would never have have
picked them on my own if they hadn't asked.

> The other larger issue is that people somehow are not willing to send
> their valid fixes to Linus after -rc4, and they flood in during the -rc1
> merge and people expect me to backport them all into .1 because they are
> lazy.

I'm 100% sure this is true. Some fixes are probably written against a -next
tree, and adding a tag means "it will automatically be backported, no need
for a separate branch for this".

> Again, specific examples are the 7 powerpc patches that are over a month
> old that were marked for the stable tree, yet didn't hit Linus's tree
> until now.  I can dig up more examples if wanted, just look at the flood
> that comes in for -rc1.
> 
> I _should_ be seeing more patches marked for stable showing up after
> -rc3 then for -rc1.  As it is, I think there's something wrong with
> maintainers relying on me to do their work for them too much, and it's
> finally pushed me to start complaining and pushing back.

I'm sure this is true. But at the same time I also think that there is
a difference between what *you* expect in -stable and what Linus expects
there. Linus says that something not suitable for past -rc4 has no place
in -stable. You want most fixes that a distro would pick. But many of the
fixes a distro would pick are probably not important enough to be picked
past -rc4 and risk regressions. So these fixes are exposed to the world
in -rc1 for the first time in their life, and unfortunately are merged
at the same time.

The problem is to find a way to mark a fix as a candidate for stable but
with a reserve for some observation period. Maybe just some indication
that the fix should not be backported before the version it's merged into
is released ? That could make sense after all : many fixes that went into
3.11-rc1 were not important enough to go into 3.10, so they can wait for
3.11 to be released before being backported. But that requires an extra
queue.

Willy

Re: [ 00/19] 3.10.1-stable review

[Greg Kroah-Hartman]

On Fri, Jul 12, 2013 at 11:43:17PM -0700, Guenter Roeck wrote:
> > And if something "fixes" an issue, then I want it in stable, just like
> > Linus wants that in his tree.
> > 
> Except if it is not critical, for a given definition of the word.

I'm not going to try to parse definitions here, but this is just crazy.

> > Don't add another tag that requires users to dig for fixes that we are
> > just too lazy to be including for all users, that way is crazy.
> > 
> Depends. If -stable rules are going to be followed by the letter, as has
> been suggested, only critical bug fixes would be applied to -stable.
> The idea here is to provide guidance to distribution maintainers
> if that is happening. This tag would mean something like "This patch
> fixes a real bug which affects the following releases, but it will not
> be applied to -stable because it is not critical".

What?  It's a fix for a problem that is "real", why would that _not_ go
into stable and Linus's tree?

Anyway, again, that's not the real issue here at all, the real issues
are, again:
  - people marking stuff for -stable that they shouldn't.
  - people sitting on stuff for -stable way longer than they should be,
    relying on me to get stuff merged for the .1 or .2 release instead
    of getting it to Linus for .0.

let's work on those two first before we start worrying about if a
specific "fix" shouldn't go into the stable tree or not.

greg k-h

Re: [ 00/19] 3.10.1-stable review

[Greg Kroah-Hartman]

On Sat, Jul 13, 2013 at 08:36:07AM +0200, Willy Tarreau wrote:
> On Fri, Jul 12, 2013 at 11:22:23PM -0700, Greg Kroah-Hartman wrote:
> > > So probably we should incite patch contributors to add a specific
> > > tag such as "Fixes: 3.5 and later", so that non-important patches
> > > do not need the Cc:stable anymore, but users who experience an issue
> > > can easily spot them and ask for their inclusion.
> > 
> > Huh?  What's wrong with the existing way people mark stable patches to
> > go back to much older kernel versions?  Is that not working well enough
> > for you?
> > 
> > And if something "fixes" an issue, then I want it in stable, just like
> > Linus wants that in his tree.
> 
> It's the difference between "this is a fix" and "please backport this
> fix into stable". As we aid in this thread, cc:stable is a bit too much
> automatic and sometimes not appropriate (not important enough fixes).

No, I've never said that.

I _want_ fixes in stable trees, as they are being done to, obviously,
fix problems.  So does Linus, why wouldn't a fix for something that is
an issue for someone _not_ go into his tree after -rc4?

Ok, for some issues, they need some time to "bake" I can understand, but
that's the exception not the rule at all.

If a distro would pick a patch up to solve a problem for a user, and
that patch is in Linus's tree, there's almost no reason that shouldn't
also be in the stable trees.

My issue is that people are trying to get me to take stuff that is _not_
fixes (i.e. build errors that are impossible to hit, or \n additions to
debugging kernel messages, or pseudo-optimizations of functions).

The other larger issue is that people somehow are not willing to send
their valid fixes to Linus after -rc4, and they flood in during the -rc1
merge and people expect me to backport them all into .1 because they are
lazy.

Again, specific examples are the 7 powerpc patches that are over a month
old that were marked for the stable tree, yet didn't hit Linus's tree
until now.  I can dig up more examples if wanted, just look at the flood
that comes in for -rc1.

I _should_ be seeing more patches marked for stable showing up after
-rc3 then for -rc1.  As it is, I think there's something wrong with
maintainers relying on me to do their work for them too much, and it's
finally pushed me to start complaining and pushing back.

greg k-h

Re: [ 00/19] 3.10.1-stable review

[Guenter Roeck]

On Fri, Jul 12, 2013 at 11:22:23PM -0700, Greg Kroah-Hartman wrote:
> On Fri, Jul 12, 2013 at 09:50:51PM +0200, Willy Tarreau wrote:
> > On Fri, Jul 12, 2013 at 10:50:08AM -0700, Linus Torvalds wrote:
> > > So I'm not going to argue that your particular patches were the
> > > problem here. I'm more arguing against your arguments than against the
> > > patches themselves. I'm not looking for some hard black-and-white
> > > rules that say "this is exactly how things have to work", because I
> > > don't think such rules can exist. But I _do_ want people to see the
> > > stable rules as fairly strict.
> > 
> > I think that maintainers are balanced between the wish to satisfy their
> > users and the risk of getting shouted at. Users expect stable versions
> > to be bug-free. Most people I talk with have a different understanding
> > of the development model than the one you present to contributors. They
> > think that the .0 release is a draft and that all bugs will be fixed in
> > -stable. I even know one person who uses -rc1 in production, claiming
> > that these ones are stable. So end users don't necessarily understand
> > the development model and ask what something they think is due : no
> > known bugs.
> > 
> > On the other hand, we've seen many regressions introduced as fixes
> > into -stable that had to be reverted afterwards, or sometimes
> > completed with a missing patch.
> > 
> > I think that maintainers use the Cc:stable as a status for commits
> > meaning "this is a bug fix". It's true that when you're digging into
> > the commits to try to qualify fixes from features, it's really hard,
> > and the new Cc:stable tag helps a lot.
> > 
> > So probably we should incite patch contributors to add a specific
> > tag such as "Fixes: 3.5 and later", so that non-important patches
> > do not need the Cc:stable anymore, but users who experience an issue
> > can easily spot them and ask for their inclusion.
> 
> Huh?  What's wrong with the existing way people mark stable patches to
> go back to much older kernel versions?  Is that not working well enough
> for you?
> 
It appears it may not be good enough for some, otherwise we would not have
this discussion.

> And if something "fixes" an issue, then I want it in stable, just like
> Linus wants that in his tree.
> 
Except if it is not critical, for a given definition of the word.

> Don't add another tag that requires users to dig for fixes that we are
> just too lazy to be including for all users, that way is crazy.
> 
Depends. If -stable rules are going to be followed by the letter, as has
been suggested, only critical bug fixes would be applied to -stable.
The idea here is to provide guidance to distribution maintainers
if that is happening. This tag would mean something like "This patch
fixes a real bug which affects the following releases, but it will not
be applied to -stable because it is not critical".

Guenter

Re: [ 00/19] 3.10.1-stable review

[Willy Tarreau]

On Fri, Jul 12, 2013 at 11:22:23PM -0700, Greg Kroah-Hartman wrote:
> > So probably we should incite patch contributors to add a specific
> > tag such as "Fixes: 3.5 and later", so that non-important patches
> > do not need the Cc:stable anymore, but users who experience an issue
> > can easily spot them and ask for their inclusion.
> 
> Huh?  What's wrong with the existing way people mark stable patches to
> go back to much older kernel versions?  Is that not working well enough
> for you?
> 
> And if something "fixes" an issue, then I want it in stable, just like
> Linus wants that in his tree.

It's the difference between "this is a fix" and "please backport this
fix into stable". As we aid in this thread, cc:stable is a bit too much
automatic and sometimes not appropriate (not important enough fixes).
But when fixes not apparently suitable for stable are merged into
mainline, having the ability to spot them is useful, whether it is for
later inclusion or just for users who'd like to run a kernel with more
fixes than the critical ones accepted for stable.

> Don't add another tag that requires users to dig for fixes that we are
> just too lazy to be including for all users, that way is crazy.

I don't think so. If there is a gap between what is fixed and what is
acceptable for -stable, this just fills this gap. It means less automatic
submissions for -stable, only the important ones, and at the same time,
a simple way of more easily spotting if a known bug affects your kernel
when you're a -stable user and are experiencing an issue.

Willy

Re: [ 00/19] 3.10.1-stable review

[Greg Kroah-Hartman]

On Fri, Jul 12, 2013 at 09:50:51PM +0200, Willy Tarreau wrote:
> On Fri, Jul 12, 2013 at 10:50:08AM -0700, Linus Torvalds wrote:
> > So I'm not going to argue that your particular patches were the
> > problem here. I'm more arguing against your arguments than against the
> > patches themselves. I'm not looking for some hard black-and-white
> > rules that say "this is exactly how things have to work", because I
> > don't think such rules can exist. But I _do_ want people to see the
> > stable rules as fairly strict.
> 
> I think that maintainers are balanced between the wish to satisfy their
> users and the risk of getting shouted at. Users expect stable versions
> to be bug-free. Most people I talk with have a different understanding
> of the development model than the one you present to contributors. They
> think that the .0 release is a draft and that all bugs will be fixed in
> -stable. I even know one person who uses -rc1 in production, claiming
> that these ones are stable. So end users don't necessarily understand
> the development model and ask what something they think is due : no
> known bugs.
> 
> On the other hand, we've seen many regressions introduced as fixes
> into -stable that had to be reverted afterwards, or sometimes
> completed with a missing patch.
> 
> I think that maintainers use the Cc:stable as a status for commits
> meaning "this is a bug fix". It's true that when you're digging into
> the commits to try to qualify fixes from features, it's really hard,
> and the new Cc:stable tag helps a lot.
> 
> So probably we should incite patch contributors to add a specific
> tag such as "Fixes: 3.5 and later", so that non-important patches
> do not need the Cc:stable anymore, but users who experience an issue
> can easily spot them and ask for their inclusion.

Huh?  What's wrong with the existing way people mark stable patches to
go back to much older kernel versions?  Is that not working well enough
for you?

And if something "fixes" an issue, then I want it in stable, just like
Linus wants that in his tree.

Don't add another tag that requires users to dig for fixes that we are
just too lazy to be including for all users, that way is crazy.

greg k-h

Re: [ 00/19] 3.10.1-stable review

[Satoru Takeuchi]

At Thu, 11 Jul 2013 15:01:17 -0700,
Greg Kroah-Hartman wrote:
> 
> <rant>
>   I'm sitting on top of over 170 more patches that have been marked for
>   the stable releases right now that are not included in this set of
>   releases.  The fact that there are this many patches for stable stuff
>   that are waiting to be merged through the main -rc1 merge window cycle
>   is worrying to me.
> 
>   Why are subsystem maintainers holding on to fixes that are
>   _supposedly_ affecting all users?  I mean, 21 powerpc core changes
>   that I don't see until a -rc1 merge?  It's as if developers don't
>   expect people to use a .0 release and are relying on me to get the
>   fixes they have burried in their trees out to users.  That's not that
>   nice.  6 "core" iscsi-target fixes?  That's the sign of either a
>   broken subsystem maintainer, or a lack of understanding what the
>   normal -rc kernel releases are supposed to be for.
> 
>   So, I've picked through the patches and dug out only those that I've
>   "guessed" at being more important than others for the 3.10.1 release.
>   I'll get to the rest of these after 3.11-rc1 is out, and eventually
>   they will make it into the stable releases, but I am going to be much
>   more strict as to what is being added (carriage return changes for
>   debug messages, really ACPI developers?)
> 
> </rant>
> 
> This is the start of the stable review cycle for the 3.10.1 release.
> There are 19 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sat Jul 13 21:45:35 UTC 2013.
> Anything received after that time might be too late.
> 

This kernel can be built and boot without any problem.
Building a kernel with this kernel also works fine.

 - Build Machine: debian jessy x86_64
   CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
   memory: 8GB

 - Test machine: debian jessy x86_64(KVM guest on the Build Machine)
   vCPU: x2
   memory: 2GB

Thanks,
Satoru

> The whole patch series can be found in one patch at:
> 	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.1-rc1.gz
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 
> -------------
> Pseudo-Shortlog of commits:
> 
> Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>     Linux 3.10.1-rc1
> 
> Michal Hocko <mhocko@suse.cz>
>     Revert "memcg: avoid dangling reference count in creation failure"
> 
> Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
>     cpufreq: Fix cpufreq regression after suspend/resume
> 
> Ben Hutchings <ben@decadent.org.uk>
>     SCSI: sd: Fix parsing of 'temporary ' cache mode prefix
> 
> Gleb Natapov <gleb@redhat.com>
>     KVM: VMX: mark unusable segment as nonpresent
> 
> J. Bruce Fields <bfields@redhat.com>
>     nfsd4: fix decoding of compounds across page boundaries
> 
> Andy Adamson <andros@netapp.com>
>     NFSv4.1 end back channel session draining
> 
> Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>     Revert "serial: 8250_pci: add support for another kind of NetMos Technology PCI 9835 Multi-I/O Controller"
> 
> Peter Hurley <peter@hurleysoftware.com>
>     tty: Reset itty for other pty
> 
> Zhang Yi <wetpzy@gmail.com>
>     futex: Take hugepages into account when generating futex_key
> 
> Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>     MAINTAINERS: add stable_kernel_rules.txt to stable maintainer information
> 
> Kees Cook <keescook@chromium.org>
>     crypto: sanitize argument for format string
> 
> Kees Cook <keescook@chromium.org>
>     block: do not pass disk names as format strings
> 
> Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
>     hpfs: better test for errors
> 
> Kees Cook <keescook@chromium.org>
>     charger-manager: Ensure event is not used as format string
> 
> Rusty Russell <rusty@rustcorp.com.au>
>     module: do percpu allocation after uniqueness check. No, really!
> 
> Jonathan Salwan <jonathan.salwan@gmail.com>
>     drivers/cdrom/cdrom.c: use kzalloc() for failing hardware
> 
> Josh Durgin <josh.durgin@inktank.com>
>     libceph: fix invalid unsigned->signed conversion for timespec encoding
> 
> majianpeng <majianpeng@gmail.com>
>     ceph: fix sleeping function called from invalid context.
> 
> Tyler Hicks <tyhicks@canonical.com>
>     libceph: Fix NULL pointer dereference in auth client code
> 
> 
> -------------
> 
> Diffstat:
> 
>  MAINTAINERS                        |  1 +
>  Makefile                           |  4 ++--
>  arch/x86/kvm/vmx.c                 | 11 +++++++++--
>  block/genhd.c                      |  2 +-
>  crypto/algapi.c                    |  3 ++-
>  drivers/block/nbd.c                |  3 ++-
>  drivers/cdrom/cdrom.c              |  2 +-
>  drivers/cpufreq/cpufreq_stats.c    |  1 +
>  drivers/power/charger-manager.c    |  2 +-
>  drivers/scsi/osd/osd_uld.c         |  2 +-
>  drivers/scsi/sd.c                  |  2 +-
>  drivers/tty/serial/8250/8250_pci.c |  4 ----
>  drivers/tty/tty_io.c               |  2 ++
>  fs/ceph/xattr.c                    |  9 +++++----
>  fs/hpfs/map.c                      |  3 ++-
>  fs/hpfs/super.c                    |  8 +++++++-
>  fs/nfs/nfs4state.c                 | 23 +++++++++++------------
>  fs/nfsd/nfs4xdr.c                  |  2 +-
>  include/linux/ceph/decode.h        |  5 -----
>  include/linux/hugetlb.h            | 16 ++++++++++++++++
>  kernel/futex.c                     |  3 ++-
>  kernel/module.c                    | 34 ++++++++++++++++++----------------
>  mm/hugetlb.c                       | 17 +++++++++++++++++
>  mm/memcontrol.c                    |  2 --
>  net/ceph/auth_none.c               |  6 ++++++
>  25 files changed, 109 insertions(+), 58 deletions(-)
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ 00/19] 3.10.1-stable review

[Jochen Striepe]

	Hello,

On Fri, Jul 12, 2013 at 04:28:20PM -0400, Steven Rostedt wrote:
> I would suspect that machines that allow unprivileged users would be
> running distro kernels, and not the latest release from Linus, and thus
> even a bug that "can allow an unprivileged user to crash the kernel" may
> still be able to sit around for a month before being submitted.
> 
> This wouldn't be the case if the bug was in older kernels that are being
> used.

On the one hand, you seem to want users with any kind of production
systems to use distro kernels. On the other hand, developers want
a broad testing base, with vanilla kernels (or better, rc) as early
as possible. You cannot get both at the same time, some kinds of bugs
just appear on production systems.

Users expect vanilla .0 releases usable as production systems, to
be updated (meaning, no new features, just stabilizing) with the
corresponding -stable series.

Just my 2p,
Jochen.

Re: [ 00/19] 3.10.1-stable review

[Justin M. Forbes]

On Fri, Jul 12, 2013 at 04:28:20PM -0400, Steven Rostedt wrote:
> 
> I would suspect that machines that allow unprivileged users would be
> running distro kernels, and not the latest release from Linus, and thus
> even a bug that "can allow an unprivileged user to crash the kernel" may
> still be able to sit around for a month before being submitted.
> 
But distros *do* ship the latest release from Linus. Fedora is often
shipping .1 releases, and sometimes .0.  This seems to be getting more
difficult though as more and more fixes have been left for stable to fix
and the Linus release contains a number of known regressions.
We know about those regressions not just from following lists, but because
we have users running rawhide kernels which are snapshots of Linus' tree
almost daily.  They see the regressions and complain.  So yeah, there are
machines out there running Linus' latest tree.

Justin

Re: [ 00/19] 3.10.1-stable review

[Guenter Roeck]

On Fri, Jul 12, 2013 at 04:47:44PM -0400, Theodore Ts'o wrote:
> On Fri, Jul 12, 2013 at 09:50:51PM +0200, Willy Tarreau wrote:
> > So probably we should incite patch contributors to add a specific
> > tag such as "Fixes: 3.5 and later", so that non-important patches
> > do not need the Cc:stable anymore, but users who experience an issue
> > can easily spot them and ask for their inclusion.
> 
> This is a really good idea.   /me likes....
> 
I agree, that would be very helpful.

Guenter

Re: [ 00/19] 3.10.1-stable review

[Theodore Ts'o]

On Fri, Jul 12, 2013 at 09:50:51PM +0200, Willy Tarreau wrote:
> So probably we should incite patch contributors to add a specific
> tag such as "Fixes: 3.5 and later", so that non-important patches
> do not need the Cc:stable anymore, but users who experience an issue
> can easily spot them and ask for their inclusion.

This is a really good idea.   /me likes....

I will likely start adopting this for the ext4 tree.

					- Ted

Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Fri, 2013-07-12 at 16:28 -0400, Steven Rostedt wrote:
> On Fri, 2013-07-12 at 16:19 -0400, Dave Jones wrote:

> I would suspect that machines that allow unprivileged users would be
> running distro kernels, and not the latest release from Linus, and thus
> even a bug that "can allow an unprivileged user to crash the kernel" may
> still be able to sit around for a month before being submitted.

That said, when I find a bug that can allow this, I still tend to make
it #1 priority and get it out as quick as possible. Maybe a week at
most. I had one such bug that only affected a -rc1 release, and I made
sure the fix made it into -rc2.

-- Steve

Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Fri, 2013-07-12 at 16:19 -0400, Dave Jones wrote:

> Your example above: If that fix was for "tracing reports wrong results", no big deal,
> everyone can live with it for a month. If it was fixing "a bug in tracing can allow
> an unprivileged user to crash the kernel", a month is unacceptable, and at
> the least we should be getting an interim fix to mitigate the problem.

And even that isn't one size fits all. If the exploit is a -rc only, or
even a newly released kernel. Is it that critical to get it fixed ASAP?
I would think that the kernel releases takes time before they get to
users main machines.

I would suspect that machines that allow unprivileged users would be
running distro kernels, and not the latest release from Linus, and thus
even a bug that "can allow an unprivileged user to crash the kernel" may
still be able to sit around for a month before being submitted.

This wouldn't be the case if the bug was in older kernels that are being
used.

-- Steve

Re: [ 00/19] 3.10.1-stable review

[Dave Jones]

On Fri, Jul 12, 2013 at 03:49:11PM -0400, Steven Rostedt wrote:
 > On Fri, 2013-07-12 at 15:35 -0400, Theodore Ts'o wrote:
 > 
 > > So the problem is that maintainers are lazy.  They don't want to go
 > > back for bug fixes that have "proven" themselves, and even if they
 > > aren't critical bug fixes, they are things which a distro maintainer
 > > or a stable kernel user might want (and sometimes stable uers are
 > > uppity enough to expect subsystem maintainers to do this back
 > > porting).  So subsystem maintainers then react by marking submits for
 > > stable even though they really should soak for a release or two before
 > > submitting them, since by marking them as submit, the commit gets
 > > pushed to stable automatically --- albeit early.
 > 
 > Actually, this is a very good point. There were one or two stable
 > patches I had pushed to linux-next that I wasn't too comfortable about.
 > If the fix goes back to older trees, I rather have them stirring in
 > linux-next and push it in the next merge window instead of pushing it to
 > Linus and have it go to stable immediately.
 > 
 > Unless its a obvious fix, I tend to take about a month from the time I
 > get a stable fix to the time I push it out. Making sure the stable fix
 > doesn't introduce new bugs.

Like most of the other examples in this thread, one size doesn't fit all though.

Your example above: If that fix was for "tracing reports wrong results", no big deal,
everyone can live with it for a month. If it was fixing "a bug in tracing can allow
an unprivileged user to crash the kernel", a month is unacceptable, and at
the least we should be getting an interim fix to mitigate the problem.

	Dave

Re: [ 00/19] 3.10.1-stable review

[Willy Tarreau]

On Fri, Jul 12, 2013 at 03:49:11PM -0400, Steven Rostedt wrote:
> On Fri, 2013-07-12 at 15:35 -0400, Theodore Ts'o wrote:
> 
> > So the problem is that maintainers are lazy.  They don't want to go
> > back for bug fixes that have "proven" themselves, and even if they
> > aren't critical bug fixes, they are things which a distro maintainer
> > or a stable kernel user might want (and sometimes stable uers are
> > uppity enough to expect subsystem maintainers to do this back
> > porting).  So subsystem maintainers then react by marking submits for
> > stable even though they really should soak for a release or two before
> > submitting them, since by marking them as submit, the commit gets
> > pushed to stable automatically --- albeit early.
> 
> Actually, this is a very good point. There were one or two stable
> patches I had pushed to linux-next that I wasn't too comfortable about.
> If the fix goes back to older trees, I rather have them stirring in
> linux-next and push it in the next merge window instead of pushing it to
> Linus and have it go to stable immediately.
> 
> Unless its a obvious fix, I tend to take about a month from the time I
> get a stable fix to the time I push it out. Making sure the stable fix
> doesn't introduce new bugs.

Indeed, which goes down to my comment somewhere else in this thread about
"Cc:stable" being used as a convenient marker for a bug fix. Let's simply
have a real marker and this should flow much smoother because end users
will ask "Dear stable maintainers, could we please merge this patch, I
need it".

Regards,
Willy

Re: [ 00/19] 3.10.1-stable review

[Willy Tarreau]

On Fri, Jul 12, 2013 at 10:50:08AM -0700, Linus Torvalds wrote:
> So I'm not going to argue that your particular patches were the
> problem here. I'm more arguing against your arguments than against the
> patches themselves. I'm not looking for some hard black-and-white
> rules that say "this is exactly how things have to work", because I
> don't think such rules can exist. But I _do_ want people to see the
> stable rules as fairly strict.

I think that maintainers are balanced between the wish to satisfy their
users and the risk of getting shouted at. Users expect stable versions
to be bug-free. Most people I talk with have a different understanding
of the development model than the one you present to contributors. They
think that the .0 release is a draft and that all bugs will be fixed in
-stable. I even know one person who uses -rc1 in production, claiming
that these ones are stable. So end users don't necessarily understand
the development model and ask what something they think is due : no
known bugs.

On the other hand, we've seen many regressions introduced as fixes
into -stable that had to be reverted afterwards, or sometimes
completed with a missing patch.

I think that maintainers use the Cc:stable as a status for commits
meaning "this is a bug fix". It's true that when you're digging into
the commits to try to qualify fixes from features, it's really hard,
and the new Cc:stable tag helps a lot.

So probably we should incite patch contributors to add a specific
tag such as "Fixes: 3.5 and later", so that non-important patches
do not need the Cc:stable anymore, but users who experience an issue
can easily spot them and ask for their inclusion.

I've already experienced the other way around, been hit by a missing
fix from 2.6.32.x that was not backported there probably because it
was considered minor (and it was for most environments), except that
it caused a complete web site to go down due to gro/gso issues with
LVS. It's typically the type of bug that is not reported by most
users, and that noone will consider critical, but once such a user
encounters it, it's far too late, the harm is already done. It's
too bad when both the bug and the fix are known and available, we
just need to *know* they exist.

While we can't ask Greg to collect all the bug fixes on the planet,
we should probably do something so that end users can more easily
spot what is relevant to their usage and from time to time ask for
these ones to be merged if that makes sense.

Willy

Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Fri, 2013-07-12 at 15:35 -0400, Theodore Ts'o wrote:

> So the problem is that maintainers are lazy.  They don't want to go
> back for bug fixes that have "proven" themselves, and even if they
> aren't critical bug fixes, they are things which a distro maintainer
> or a stable kernel user might want (and sometimes stable uers are
> uppity enough to expect subsystem maintainers to do this back
> porting).  So subsystem maintainers then react by marking submits for
> stable even though they really should soak for a release or two before
> submitting them, since by marking them as submit, the commit gets
> pushed to stable automatically --- albeit early.

Actually, this is a very good point. There were one or two stable
patches I had pushed to linux-next that I wasn't too comfortable about.
If the fix goes back to older trees, I rather have them stirring in
linux-next and push it in the next merge window instead of pushing it to
Linus and have it go to stable immediately.

Unless its a obvious fix, I tend to take about a month from the time I
get a stable fix to the time I push it out. Making sure the stable fix
doesn't introduce new bugs.

-- Steve

Re: [ 00/19] 3.10.1-stable review

[Theodore Ts'o]

The unwritten criteria that I've seen used (and sometimes even
discussed on mailing lists) is that if it's something that distro
kernel maintainers would want, then it's fit for stable.  Now, there's
a grey area here.  The criteria before distro's "golden master" has
been released is quite different compared to a criteria for a Service
Pack 5 kernel.  There's also a hjuge difference between a patch which
has just hit mainline during the merge window, and a bug fix which has
been in Linus's tree for weeks or months.  It's likely that a bug fix
which has been in the kernel since 3.8, even if it is not "critical"
is one which might be suitable merging for 3.4.  Heck, I've even had
users screaming at me that it was somehow my duty as the ext4
maintainer to find these commits and backport them to 3.4 or 3.2.  (Of
course, I blow them off.  :-)

So the problem is that maintainers are lazy.  They don't want to go
back for bug fixes that have "proven" themselves, and even if they
aren't critical bug fixes, they are things which a distro maintainer
or a stable kernel user might want (and sometimes stable uers are
uppity enough to expect subsystem maintainers to do this back
porting).  So subsystem maintainers then react by marking submits for
stable even though they really should soak for a release or two before
submitting them, since by marking them as submit, the commit gets
pushed to stable automatically --- albeit early.

Now, I'm not condoning this practice; but I suspect this is at least
partially the reason why some maintainers have gotten more aggressive
about marking patches for stable and not pushing them to mainline earlier.

If it really is the case that patches that are marked for -stable are
patches that should just be sent to linus pre-rc4, and patches that
had just been added to the subsystem maintainer tree a few weeks
before the merge window shouldn't be automatically be merged into
stable, maybe the right answer is that the stable kernel maintainers
shouldn't be automatically including _any_ patches that are marked for
stable which are sent to mainline during the merge window.

       	     	      	 	  	 - Ted

Re: [ 00/19] 3.10.1-stable review

[Guenter Roeck]

On Fri, Jul 12, 2013 at 10:50:08AM -0700, Linus Torvalds wrote:
> On Fri, Jul 12, 2013 at 10:31 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > Stable rules say: "It must fix a real bug that bothers people (not a, "This
> > could be a problem..." type thing). All the above fit that rule.
> 
> You cut out the important part:
> 
>  - It must fix a problem that causes a build error (but not for things
>    marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
>    security issue, or some "oh, that's not good" issue.  In short, something
>    critical.
> 
> That list is not a "or" list, it's an "and" list - it needs to follow
> *all* the rules. The exception is the "New device IDs and quirks are
> also accepted", which maybe should be made more clearly separate.
> 
> > But are those patches critical ? Sure, people complained about getting alarms
> > on the wrong attribute or not getting alarms when they expected to, but critical ?
> > No, unless some application at some point starts to shut down the system because
> > of a false alarm. So I guess the above should not go into -stable, then.
> 
> Right. And that's what the stable rules say. It's not enough to be a
> "real bug". It needs to be critical. If it's something that has been
> around forever, there needs to be a stronger argument than "I found a
> bug" for marking it for stable.
> 
> > Problem is with "bothers people" vs. "critical".
> 
> There is no "vs".
> 
> The "real bug that bothers people" rule is not meant to be seen as a
> separate rule from the next rule (already quoted above), it needs to
> be *in*addition*to*.
> 
I understand, but that is theory (mathematical interpretation)
vs. reality. The "real bug ... must bother people" is the rule that
is used in practice today. Problem may be that not even that rule
is really followed anymore.

> For example, we have the "causes a build error" case - but that should
> be seen in the "real bug that bothers people" light, and you should
> not mark Kconfig fixes for stable unless they have actually caused
> problems. Why? Because most Kconfig problems tend to be for
> unrealistic situations like "Oh, if I turn off PCI or networking, this
> driver no longer builds". Sure, that is a bug, and it's a bug that
> causes build error, but it's not something that bothers real people,
> because if you turn off networking or turn off PCI, you damn well had
> better also turn off all the other crap you don't need.
> 
> Yes, there are always going to be gray areas. And Greg is obviously a
> much nicer person than I am, so he's likely *always* going to be more
> generous about those gray aras than I would be. And within reason, I
> think that's perfectly fine - if there's a few patches that get marked
> for stable because it's easier for people to sneak them in that way,
> whatever. It becomes a problem only when it gets to be *too* common,
> which is apparently what happened now.
> 
> So I'm not going to argue that your particular patches were the
> problem here. I'm more arguing against your arguments than against the
> patches themselves. I'm not looking for some hard black-and-white
> rules that say "this is exactly how things have to work", because I
> don't think such rules can exist. But I _do_ want people to see the

I am perfectly fine with that, but then you'll have to accept that
the rules will be bent to the point where we are now ...  if there are
no clear rules, bending the rules until someone screams seems to be
the best if not the only way to figure out how things are supposed
to work.

> stable rules as fairly strict. And in particular, I really don't think
> people should see "post-rc4" to be any different from "stable".
> 
My personal rule so far has been more pragmatic - if it is going to bother
me as maintainer, I want it fixed in -stable. Otherwise I'll be bogged down
forever having to tell people to use a later kernel to get a bug fixed.
I don't really have enough time to do that, often people don't even have
that option.

Guenter

Re: [ 00/19] 3.10.1-stable review

[Linus Torvalds]

On Fri, Jul 12, 2013 at 10:31 AM, Guenter Roeck <linux@roeck-us.net> wrote:
>
> Stable rules say: "It must fix a real bug that bothers people (not a, "This
> could be a problem..." type thing). All the above fit that rule.

You cut out the important part:

 - It must fix a problem that causes a build error (but not for things
   marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
   security issue, or some "oh, that's not good" issue.  In short, something
   critical.

That list is not a "or" list, it's an "and" list - it needs to follow
*all* the rules. The exception is the "New device IDs and quirks are
also accepted", which maybe should be made more clearly separate.

> But are those patches critical ? Sure, people complained about getting alarms
> on the wrong attribute or not getting alarms when they expected to, but critical ?
> No, unless some application at some point starts to shut down the system because
> of a false alarm. So I guess the above should not go into -stable, then.

Right. And that's what the stable rules say. It's not enough to be a
"real bug". It needs to be critical. If it's something that has been
around forever, there needs to be a stronger argument than "I found a
bug" for marking it for stable.

> Problem is with "bothers people" vs. "critical".

There is no "vs".

The "real bug that bothers people" rule is not meant to be seen as a
separate rule from the next rule (already quoted above), it needs to
be *in*addition*to*.

For example, we have the "causes a build error" case - but that should
be seen in the "real bug that bothers people" light, and you should
not mark Kconfig fixes for stable unless they have actually caused
problems. Why? Because most Kconfig problems tend to be for
unrealistic situations like "Oh, if I turn off PCI or networking, this
driver no longer builds". Sure, that is a bug, and it's a bug that
causes build error, but it's not something that bothers real people,
because if you turn off networking or turn off PCI, you damn well had
better also turn off all the other crap you don't need.

Yes, there are always going to be gray areas. And Greg is obviously a
much nicer person than I am, so he's likely *always* going to be more
generous about those gray aras than I would be. And within reason, I
think that's perfectly fine - if there's a few patches that get marked
for stable because it's easier for people to sneak them in that way,
whatever. It becomes a problem only when it gets to be *too* common,
which is apparently what happened now.

So I'm not going to argue that your particular patches were the
problem here. I'm more arguing against your arguments than against the
patches themselves. I'm not looking for some hard black-and-white
rules that say "this is exactly how things have to work", because I
don't think such rules can exist. But I _do_ want people to see the
stable rules as fairly strict. And in particular, I really don't think
people should see "post-rc4" to be any different from "stable".

If anything, I think post-rc4 should be easier to get into, if only
because post-rc4 has the additional "hey, if it's new code that hasn't
seen a release yet, we can be much more aggressive about it". For
example, I think I'm *much* more open to reverting new commits
entirely in the late rc's than we should ever be for stable.

            Linus

Re: [ 00/19] 3.10.1-stable review

[Guenter Roeck]

On Fri, Jul 12, 2013 at 08:22:27AM -0700, Linus Torvalds wrote:
> On Fri, Jul 12, 2013 at 7:15 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> >> >
> >> > I get the impression as soon as we hit -rc1, some maintainers immediately
> >> > go into "OH SHIT, I CAN'T SEND PATCHES OR LINUS WILL SHOUT AT ME" mode.
> >>
> >> I agree.  But it seems that I need to now start shouting at them :(
> >
> > Just like others, I now have a cutoff-point for -stable patches. Depending on
> > the severity of a bug, it is somewhere between -rc4 and -rc6. After -rc6 I only
> > push regressions and crash fixes; the rest has to wait for the commit window.
> 
> So regressions, crash fixes (and security issues) is exactly what I
> want to get after -rc3 or so. And yes, I will start shouting at people
> if other things show up.
> 
> However, I think your comments clearly show the problem:
> 
> > So, yes, there are a couple of hwmon patches in your list.
> >
> > From a maintainer perspective, seems to me we are stuck between a rock and a
> > hard place. Yes, I would prefer to push all -stable material even late in the
> > -rc game, but that is not how things work nowadays anymore.
> 
> That's f*cking sad. You know *why* it's sad?
> 
> Go read the rules for stable patches. Really.
> 
41fa9a944 hwmon: (nct6775) Drop unsupported fan alarm attributes for NCT6775
b1d2bff6a hwmon: (nct6775) Fix temperature alarm attributes

Stable rules say: "It must fix a real bug that bothers people (not a, "This
could be a problem..." type thing). All the above fit that rule.

But are those patches critical ? Sure, people complained about getting alarms
on the wrong attribute or not getting alarms when they expected to, but critical ?
No, unless some application at some point starts to shut down the system because
of a false alarm. So I guess the above should not go into -stable, then.

> Because the rules for stable patches are the rules _I_ use for that
> late -rc stuff, and is pretty much exactly what you yourself described
> as "this is what I send Linus after -rc4".
> 
> Now, that should make you think about THE ABSOLUTE CRAP YOU MARK FOR -stable!
> 
> If it isn't important enough to send to me after -rc4, then it damn
> well isn't important enough to mark for stable either!
> 
> It really is that simple.
> 
> > This should really be discussed at the Kernel Summit. Overall, I don't really
> > care too much how to handle it. Just tell me. The outlook of "Either Linus
> > will shout at you or Greg will" doesn't sound like a good solution, though.
> 
> Listen to yourself. In fact, there is a damn good solution": don't
> mark crap for stable, and don't send crap to me after -rc4.
> 
> If it doesn't fit the stable rules, they should go in the next merge
> window. It really is that simple. You even (unwittingly) pretty much
> described the stable rules, but then you apparently didn't understand
> that those were the rules for -stable too.
> 
Problem is with "bothers people" vs. "critical". A lot of things bother people
which are not critical. I personally have to back-port patches from upstream
into my company's tree to fix bugs. Do those patches always fix critical bugs ?
No, but I still have to have them fixed. But I would still prefer to have those
patches applied to -stable, first to ensure broad test coverage but also to
prevent others to hit the same problems I had, and in the hope they do the same
favor to me at some point.

Overall, given your feedback, I think that stable-rules should be clarified.
"real bug ... bothers people" should replaced with a clear statement such as
"It must fix a critical bug", and the list of examples should follow (instead
of making the term "critical" a side note of the list of examples).

What you are really saying is that -stable shall not be used by anyone to
assume that "this is a kernel you can use in your distribution", but that
you _expect_ every distribution to run patched kernels and to spend a lot
of time tracking down and applying upstream patches. Like Greg pointed out
in one of his replies- you _want_ to put more burden on distribution maintainers.

Personally I am not sure if that really makes much sense - I for my part
would prefer to have the official stable rules follow the "must fix a real
bug that bothers people" rule rather than the "must fix a critical bug"
rule, and have stable kernels which need as few as possible additional
patches on top - all that for the simple reason to get as much test coverage
as possible on a common baseline. But that may be just me.

> Of course, I suspect I see why this happens. Greg doesn't shout as
> much as me, and he has been taking any random patches into -stable. So
> the end result is that people think it's easier to mark things for
> -stable than it is to show that it actualy *is* stable, and they are
> trying to use -stable as a way to get any random late fixes in.
> 
> That is not how stable should work. When stable started, it had some
> rather clear rules. It's not for "fixes". It was meant to be solely
> for big issues.
> 
Please keep in mind that not all of us were there at that time.

> The thing you just described that you put a stable tag on is *EXACTLY*
> the things that should not be marked for stable. For *EXACTLY* the
> same reason that you realized you shouldn't push it to me after -rc4.
> 
> Do you really not see this?
> 
Unfortunately, my psychic capabilities really lag behind. Really, there
are many rules in many areas in the kernel one can only learn from practice
and from trying, not because it is written down. Where is it written down
how submit patches for inclusion into -stable for anything in the /net
tree ? The one way to find out is to send a request to -stable and get
flamed at for doing so.

> Greg, the reason you get a lot of stable patches seems to be that you
> make it easy to act as a door-mat. Clearly at least some people say "I
> know this patch isn't important enough to send to Linus, but I know
> Greg will silently accept it after the fact, so I'll just wait and
> mark it for stable".
> 
The point isn't really "Greg will silently accept it", but that there
are many unwritten rules which one has to learn. Like with pretty much
everything else, that also applies to -stable submission rules.

I have heard many maintainers state "not critical enough for -rc, I will
submit it in the commit window and mark it for stable". Ok, I started
to follow that approach as well, and you may feel free to shout at me
for doing it.

But, really, folks, it _would_ help if you would consider clarifying the rules.
Which may include more shouting by Greg - after all, we all learn from being
shouted at.

Guenter

Re: [ 00/19] 3.10.1-stable review

[Greg Kroah-Hartman]

On Fri, Jul 12, 2013 at 05:20:29PM +0000, Shuah Khan wrote:
> On 07/11/2013 04:24 PM, Greg Kroah-Hartman wrote:
> 
> >
> > This is the start of the stable review cycle for the 3.10.1 release.
> > There are 19 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sat Jul 13 21:45:35 UTC 2013.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > 	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.1-rc1.gz
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
> 
> Patches applied cleanly to 3.0.85, 3.4.52, 3.9.9, and 3.10
> 
> Compiled and booted on the following systems:
> 
> Samsung Series 9 900X4C Intel Corei5:
>      (3.4.53-rc1, 3.9.10-rc1, 3.10.1-rc1)
> HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics:
>      (3.0.86-rc1, 3.4.53-rc1, 3.9.10-rc1, and 3.10.1-rc1)
> 
> dmesgs for all releases look good. No regressions compared to the previous
> dmesgs for each of these releases. dmesg emerg, crit, alert, err are clean.
> No regressions in warn.
> 
> Cross-compile testing:
> HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2:
>      (3.0.86-rc1, 3.4.53-rc1, 3.9.10-rc1, and 3.10.1-rc1)

Great, thanks for testing all of these and letting me know.

greg k-h

Re: [ 00/19] 3.10.1-stable review

[Shuah Khan]

On 07/11/2013 04:24 PM, Greg Kroah-Hartman wrote:

>
> This is the start of the stable review cycle for the 3.10.1 release.
> There are 19 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat Jul 13 21:45:35 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.1-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Patches applied cleanly to 3.0.85, 3.4.52, 3.9.9, and 3.10

Compiled and booted on the following systems:

Samsung Series 9 900X4C Intel Corei5:
     (3.4.53-rc1, 3.9.10-rc1, 3.10.1-rc1)
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics:
     (3.0.86-rc1, 3.4.53-rc1, 3.9.10-rc1, and 3.10.1-rc1)

dmesgs for all releases look good. No regressions compared to the previous
dmesgs for each of these releases. dmesg emerg, crit, alert, err are clean.
No regressions in warn.

Cross-compile testing:
HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2:
     (3.0.86-rc1, 3.4.53-rc1, 3.9.10-rc1, and 3.10.1-rc1)

Cross-compile tests results:

alpha: defconfig passed on all
arm: defconfig passed on all
arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.9.y, and 3.10.y
c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, 3.9.y, and 3.10.y
mips: defconfig passed on all
mipsel: defconfig passed on all
powerpc: wii_defconfig passed on all
sh: defconfig passed on all
sparc: defconfig passed on all
tile: tilegx_defconfig passed on all

-- Shuah

Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research 
America (Silicon Valley) shuah.kh@samsung.com | (970) 672-0658

Re: [ 00/19] 3.10.1-stable review

[Greg Kroah-Hartman]

On Fri, Jul 12, 2013 at 12:35:26PM -0400, Josh Boyer wrote:
> On Fri, Jul 12, 2013 at 12:17 PM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >
> >> On Fri, Jul 12, 2013 at 8:47 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> >> >
> >> > I tend to hold things off after -rc4 because you scare me more than Greg
> >> > does ;-)
> >>
> >> Have you guys *seen* Greg? The guy is a freakish giant. He *should*
> >> scare you. He might squish you without ever even noticing.
> >
> > Greg might be a giant and he might squish people without ever even
> > noticing, but that's just a grave, deadly physical threat no real kernel
> > hacker ever feels threatened by. (Not much can hurt us deep in our dark
> > basements after all, except maybe earthquakes, gamma ray eruptions and Mom
> > trying to clean up around the computers.)
> >
> > So Greg, if you want it all to change, create some _real_ threat: be frank
> > with contributors and sometimes swear a bit. That will cut your mailqueue
> > in half, promise!

Ok, I'll channel my "inner Linus" and take a cue from my kids and start
swearing more.

> I don't think it's that simple.  The problem here isn't that Greg is
> being too nice.  The problem is that people are holding back fixes
> from Linus' tree.  Greg might be able to yell at maintainers more, but
> if he does it's after the fact and it's sort of a too late situation.
> Those fixes should probably get in the tree because they should
> probably have been in the .0 release to begin with.  I don't envy Greg
> here.

I'm going to start pushing back on the "obviously this shouldn't be for
stable" patches, and have done so, but you are right, the real issue is
that it seems that subsystem maintainers are being lazy and just not
sending the patches to Linus at all, because they "know" I will pick
them up for the .1 or .2 release.

Specific example is, again, the powerpc patches.  Out of 21 patches
marked for stable that showed up in the -rc1 merge, at least 7 of them
had _plenty_ of time to get into 3.10.0 as they are weeks, and sometimes
months, old.  Some of the other ones seem _very_ new, being only days
old before they hit Linus's tree, which makes me worry about them for
totally different reasons (i.e. not tested in linux-next at all.)

I can put a "delay" on patches to not hit a stable release for a few
weeks until they get some testing in Linus's tree, but in reality,
what's that going to help with?

I guess I can just not apply them at all, tough-love and all that, but
that just puts an extra burden on the distro kernel maintainers to have
to go dig up the fixes for their users.

Although really, who cares about powerpc anymore :)

> More seriously though, those -stable fixes queued up for months show
> up there first.  Perhaps if we watch the trees feeding into linux-next
> for a bit for fixes tagged with -stable in the middle -rc windows, we
> can prod maintainers more.

Someone once did this, and I agree, it should be done more.  I'll see
about knocking up a script to try to automate it a bit to make it easier
for me to do that.  Dave has proven that we need to poke maintainers
more to get their act together and push fixes to Linus.

greg k-h

Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Fri, 2013-07-12 at 08:55 -0700, Linus Torvalds wrote:
> On Fri, Jul 12, 2013 at 8:47 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > I tend to hold things off after -rc4 because you scare me more than Greg
> > does ;-)
> 
> Have you guys *seen* Greg? The guy is a freakish giant. He *should*
> scare you. He might squish you without ever even noticing.

But Greg's a gentle giant. You're more like an angry penguin charging at
you in excess of 100 mph.

-- Steve

Re: [ 00/19] 3.10.1-stable review

[Josh Boyer]

On Fri, Jul 12, 2013 at 12:35 PM, Josh Boyer <jwboyer@gmail.com> wrote:
> On Fri, Jul 12, 2013 at 12:17 PM, Ingo Molnar <mingo@kernel.org> wrote:
>>
>> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>
>>> On Fri, Jul 12, 2013 at 8:47 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
>>> >
>>> > I tend to hold things off after -rc4 because you scare me more than Greg
>>> > does ;-)
>>>
>>> Have you guys *seen* Greg? The guy is a freakish giant. He *should*
>>> scare you. He might squish you without ever even noticing.
>>
>> Greg might be a giant and he might squish people without ever even
>> noticing, but that's just a grave, deadly physical threat no real kernel
>> hacker ever feels threatened by. (Not much can hurt us deep in our dark
>> basements after all, except maybe earthquakes, gamma ray eruptions and Mom
>> trying to clean up around the computers.)
>>
>> So Greg, if you want it all to change, create some _real_ threat: be frank
>> with contributors and sometimes swear a bit. That will cut your mailqueue
>> in half, promise!
>
> I don't think it's that simple.  The problem here isn't that Greg is
> being too nice.  The problem is that people are holding back fixes
> from Linus' tree.  Greg might be able to yell at maintainers more, but
> if he does it's after the fact and it's sort of a too late situation.
> Those fixes should probably get in the tree because they should
> probably have been in the .0 release to begin with.  I don't envy Greg
> here.
>
> I know... let's push this off onto linux-next. It isn't like Stephen
> has anything better to do anyway ;).
>
> More seriously though, those -stable fixes queued up for months show

Er.. probably should have said weeks or "a while" or something, not months.

> up there first.  Perhaps if we watch the trees feeding into linux-next
> for a bit for fixes tagged with -stable in the middle -rc windows, we
> can prod maintainers more.

Re: [ 00/19] 3.10.1-stable review

[Josh Boyer]

On Fri, Jul 12, 2013 at 12:17 PM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> On Fri, Jul 12, 2013 at 8:47 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
>> >
>> > I tend to hold things off after -rc4 because you scare me more than Greg
>> > does ;-)
>>
>> Have you guys *seen* Greg? The guy is a freakish giant. He *should*
>> scare you. He might squish you without ever even noticing.
>
> Greg might be a giant and he might squish people without ever even
> noticing, but that's just a grave, deadly physical threat no real kernel
> hacker ever feels threatened by. (Not much can hurt us deep in our dark
> basements after all, except maybe earthquakes, gamma ray eruptions and Mom
> trying to clean up around the computers.)
>
> So Greg, if you want it all to change, create some _real_ threat: be frank
> with contributors and sometimes swear a bit. That will cut your mailqueue
> in half, promise!

I don't think it's that simple.  The problem here isn't that Greg is
being too nice.  The problem is that people are holding back fixes
from Linus' tree.  Greg might be able to yell at maintainers more, but
if he does it's after the fact and it's sort of a too late situation.
Those fixes should probably get in the tree because they should
probably have been in the .0 release to begin with.  I don't envy Greg
here.

I know... let's push this off onto linux-next. It isn't like Stephen
has anything better to do anyway ;).

More seriously though, those -stable fixes queued up for months show
up there first.  Perhaps if we watch the trees feeding into linux-next
for a bit for fixes tagged with -stable in the middle -rc windows, we
can prod maintainers more.

josh

Re: [ 00/19] 3.10.1-stable review

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Fri, Jul 12, 2013 at 8:47 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > I tend to hold things off after -rc4 because you scare me more than Greg
> > does ;-)
> 
> Have you guys *seen* Greg? The guy is a freakish giant. He *should*
> scare you. He might squish you without ever even noticing.

Greg might be a giant and he might squish people without ever even 
noticing, but that's just a grave, deadly physical threat no real kernel 
hacker ever feels threatened by. (Not much can hurt us deep in our dark 
basements after all, except maybe earthquakes, gamma ray eruptions and Mom 
trying to clean up around the computers.)

So Greg, if you want it all to change, create some _real_ threat: be frank 
with contributors and sometimes swear a bit. That will cut your mailqueue 
in half, promise!

Thanks,

	Ingo

Re: [ 00/19] 3.10.1-stable review

[Linus Torvalds]

On Fri, Jul 12, 2013 at 8:47 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> I tend to hold things off after -rc4 because you scare me more than Greg
> does ;-)

Have you guys *seen* Greg? The guy is a freakish giant. He *should*
scare you. He might squish you without ever even noticing.

              Linus

Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Fri, 2013-07-12 at 08:22 -0700, Linus Torvalds wrote:

> Listen to yourself. In fact, there is a damn good solution": don't
> mark crap for stable, and don't send crap to me after -rc4.
> 

I tend to hold things off after -rc4 because you scare me more than Greg
does ;-)


Actually, as I consider tracing a second class citizen, the things that
I tend not to send you, but instead mark for stable, are things that can
cause events to be dropped, or just incorrect trace data. Like a
tracepoint saying preemption is off when it is enabled. If I find a bug
that can cause some minor incorrect trace data to occur, and its after
-rc4, I tend to just mark it with a stable tag and wait for the merge
window to occur. I don't mean regressions either. Usually, the incorrect
data comes from something new for that release, or something that's been
there forever (like commit 11034ae9c20f4057a6127fc965906417978e69b2).

Should those be sent to you late in the game as well? 

For the 3.11 merge window, I had quite a bit of stable tags, but those
were commits that I would have sent to you but they were found very
late, and by the time I was satisfied with the test output, you had
already opened the window.

-- Steve

Re: [ 00/19] 3.10.1-stable review

[Linus Torvalds]

On Fri, Jul 12, 2013 at 7:15 AM, Guenter Roeck <linux@roeck-us.net> wrote:
>> >
>> > I get the impression as soon as we hit -rc1, some maintainers immediately
>> > go into "OH SHIT, I CAN'T SEND PATCHES OR LINUS WILL SHOUT AT ME" mode.
>>
>> I agree.  But it seems that I need to now start shouting at them :(
>
> Just like others, I now have a cutoff-point for -stable patches. Depending on
> the severity of a bug, it is somewhere between -rc4 and -rc6. After -rc6 I only
> push regressions and crash fixes; the rest has to wait for the commit window.

So regressions, crash fixes (and security issues) is exactly what I
want to get after -rc3 or so. And yes, I will start shouting at people
if other things show up.

However, I think your comments clearly show the problem:

> So, yes, there are a couple of hwmon patches in your list.
>
> From a maintainer perspective, seems to me we are stuck between a rock and a
> hard place. Yes, I would prefer to push all -stable material even late in the
> -rc game, but that is not how things work nowadays anymore.

That's f*cking sad. You know *why* it's sad?

Go read the rules for stable patches. Really.

Because the rules for stable patches are the rules _I_ use for that
late -rc stuff, and is pretty much exactly what you yourself described
as "this is what I send Linus after -rc4".

Now, that should make you think about THE ABSOLUTE CRAP YOU MARK FOR -stable!

If it isn't important enough to send to me after -rc4, then it damn
well isn't important enough to mark for stable either!

It really is that simple.

> This should really be discussed at the Kernel Summit. Overall, I don't really
> care too much how to handle it. Just tell me. The outlook of "Either Linus
> will shout at you or Greg will" doesn't sound like a good solution, though.

Listen to yourself. In fact, there is a damn good solution": don't
mark crap for stable, and don't send crap to me after -rc4.

If it doesn't fit the stable rules, they should go in the next merge
window. It really is that simple. You even (unwittingly) pretty much
described the stable rules, but then you apparently didn't understand
that those were the rules for -stable too.

Of course, I suspect I see why this happens. Greg doesn't shout as
much as me, and he has been taking any random patches into -stable. So
the end result is that people think it's easier to mark things for
-stable than it is to show that it actualy *is* stable, and they are
trying to use -stable as a way to get any random late fixes in.

That is not how stable should work. When stable started, it had some
rather clear rules. It's not for "fixes". It was meant to be solely
for big issues.

The thing you just described that you put a stable tag on is *EXACTLY*
the things that should not be marked for stable. For *EXACTLY* the
same reason that you realized you shouldn't push it to me after -rc4.

Do you really not see this?

Greg, the reason you get a lot of stable patches seems to be that you
make it easy to act as a door-mat. Clearly at least some people say "I
know this patch isn't important enough to send to Linus, but I know
Greg will silently accept it after the fact, so I'll just wait and
mark it for stable".

You may need to learn to shout at people.

                   Linus

Re: [ 00/19] 3.10.1-stable review

[Guenter Roeck]

On Thu, Jul 11, 2013 at 03:44:55PM -0700, Greg Kroah-Hartman wrote:
> On Thu, Jul 11, 2013 at 06:29:35PM -0400, Dave Jones wrote:
> > On Thu, Jul 11, 2013 at 03:01:17PM -0700, Greg Kroah-Hartman wrote:
> >  > <rant>
> >  >   I'm sitting on top of over 170 more patches that have been marked for
> >  >   the stable releases right now that are not included in this set of
> >  >   releases.  The fact that there are this many patches for stable stuff
> >  >   that are waiting to be merged through the main -rc1 merge window cycle
> >  >   is worrying to me.
> >  > 
> >  >   Why are subsystem maintainers holding on to fixes that are
> >  >   _supposedly_ affecting all users?  I mean, 21 powerpc core changes
> >  >   that I don't see until a -rc1 merge?  It's as if developers don't
> >  >   expect people to use a .0 release and are relying on me to get the
> >  >   fixes they have burried in their trees out to users.  That's not that
> >  >   nice.  6 "core" iscsi-target fixes?  That's the sign of either a
> >  >   broken subsystem maintainer, or a lack of understanding what the
> >  >   normal -rc kernel releases are supposed to be for.
> > 
> > I get the impression as soon as we hit -rc1, some maintainers immediately
> > go into "OH SHIT, I CAN'T SEND PATCHES OR LINUS WILL SHOUT AT ME" mode.
> 
> I agree.  But it seems that I need to now start shouting at them :(
> 
Just like others, I now have a cutoff-point for -stable patches. Depending on
the severity of a bug, it is somewhere between -rc4 and -rc6. After -rc6 I only
push regressions and crash fixes; the rest has to wait for the commit window.

So, yes, there are a couple of hwmon patches in your list.

>From a maintainer perspective, seems to me we are stuck between a rock and a
hard place. Yes, I would prefer to push all -stable material even late in the
-rc game, but that is not how things work nowadays anymore.

This should really be discussed at the Kernel Summit. Overall, I don't really
care too much how to handle it. Just tell me. The outlook of "Either Linus
will shout at you or Greg will" doesn't sound like a good solution, though.

Guenter

Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Thu, 2013-07-11 at 15:44 -0700, Greg Kroah-Hartman wrote:

> > For .10 I had to start making a list of "shit that's broken that there's
> > an outstanding patch for" and nagging people to send them week after week.
> > Every time I reported a new bug I'd hit, I'd have to explain I wasn't running
> > Linus' tree because there was so much other crap I had to carry just to
> > get things to a baseline of stability before starting tests.
> > 
> > By rc7 things got a lot better, but if we have fixes sitting around in
> > git trees for weeks on end with no progress, that kinda sucks.
> 
> We have patches with assigned CVE numbers sitting in subsystem trees
> that didn't hit Linus's tree until this merge window.  Now granted, I
> don't necessarily agree that they were worth CVEs, but really, holding
> them off from being merged for 2 months or so is really bad, and means
> that something seems a bit broken with our development process.
> 
> And thanks for nagging people, I really appreciate it, sad it's
> necessary.

What I try to do is, get all "stable" patches in before -rc4 is out.
Once -rc4 is out, then I get a bit more picky with what to push to
Linus. If it's not a regression (something that's been broken for a
while) I don't push it. -rc5, I get even pickier, and by -rc6 and
beyond, I only push things that may crash the kernel. If things just
give bad output (for tracing), I tag it with stable and wait for the
merge window.

3.10 was actually really bad for me. I had some major changes done to
ftrace, and there were a lot of patches sent to me after -rc4 came out.
A lot of them were nits and didn't crash the kernel, thus I only tagged
them with stable. Some of them, we didn't get correct until Linus opened
the merge window.

Maybe this would be a good KS topic. What exactly is appropriate to push
during the -rc's. Perhaps have criteria for the -rc levels.

-rc1-3, take all bug fixes.

-rc4,5, regressions, and more substantial bugs

-rc6-..  get your act together. Only critical bug fixes.

??

-- Steve

Re: [ 00/19] 3.10.1-stable review

[Greg Kroah-Hartman]

On Thu, Jul 11, 2013 at 06:29:35PM -0400, Dave Jones wrote:
> On Thu, Jul 11, 2013 at 03:01:17PM -0700, Greg Kroah-Hartman wrote:
>  > <rant>
>  >   I'm sitting on top of over 170 more patches that have been marked for
>  >   the stable releases right now that are not included in this set of
>  >   releases.  The fact that there are this many patches for stable stuff
>  >   that are waiting to be merged through the main -rc1 merge window cycle
>  >   is worrying to me.
>  > 
>  >   Why are subsystem maintainers holding on to fixes that are
>  >   _supposedly_ affecting all users?  I mean, 21 powerpc core changes
>  >   that I don't see until a -rc1 merge?  It's as if developers don't
>  >   expect people to use a .0 release and are relying on me to get the
>  >   fixes they have burried in their trees out to users.  That's not that
>  >   nice.  6 "core" iscsi-target fixes?  That's the sign of either a
>  >   broken subsystem maintainer, or a lack of understanding what the
>  >   normal -rc kernel releases are supposed to be for.
> 
> I get the impression as soon as we hit -rc1, some maintainers immediately
> go into "OH SHIT, I CAN'T SEND PATCHES OR LINUS WILL SHOUT AT ME" mode.

I agree.  But it seems that I need to now start shouting at them :(

> And the later in -rc we are, the more reluctant some people seem to be
> at sending stuff. Which, for slowing things down as we go through -rc is great,
> but not so much when people stop sending _everything_ and start thinking
> "I'll just get it in stable in a few weeks".

The 20 powerpc patches are proof of that.  I'm amost considering just
not applying them at all, as obviously they weren't all that important.

> For .10 I had to start making a list of "shit that's broken that there's
> an outstanding patch for" and nagging people to send them week after week.
> Every time I reported a new bug I'd hit, I'd have to explain I wasn't running
> Linus' tree because there was so much other crap I had to carry just to
> get things to a baseline of stability before starting tests.
> 
> By rc7 things got a lot better, but if we have fixes sitting around in
> git trees for weeks on end with no progress, that kinda sucks.

We have patches with assigned CVE numbers sitting in subsystem trees
that didn't hit Linus's tree until this merge window.  Now granted, I
don't necessarily agree that they were worth CVEs, but really, holding
them off from being merged for 2 months or so is really bad, and means
that something seems a bit broken with our development process.

And thanks for nagging people, I really appreciate it, sad it's
necessary.

greg k-h

Re: [ 00/19] 3.10.1-stable review

[Dave Jones]

On Thu, Jul 11, 2013 at 03:01:17PM -0700, Greg Kroah-Hartman wrote:
 > <rant>
 >   I'm sitting on top of over 170 more patches that have been marked for
 >   the stable releases right now that are not included in this set of
 >   releases.  The fact that there are this many patches for stable stuff
 >   that are waiting to be merged through the main -rc1 merge window cycle
 >   is worrying to me.
 > 
 >   Why are subsystem maintainers holding on to fixes that are
 >   _supposedly_ affecting all users?  I mean, 21 powerpc core changes
 >   that I don't see until a -rc1 merge?  It's as if developers don't
 >   expect people to use a .0 release and are relying on me to get the
 >   fixes they have burried in their trees out to users.  That's not that
 >   nice.  6 "core" iscsi-target fixes?  That's the sign of either a
 >   broken subsystem maintainer, or a lack of understanding what the
 >   normal -rc kernel releases are supposed to be for.

I get the impression as soon as we hit -rc1, some maintainers immediately
go into "OH SHIT, I CAN'T SEND PATCHES OR LINUS WILL SHOUT AT ME" mode.

And the later in -rc we are, the more reluctant some people seem to be
at sending stuff. Which, for slowing things down as we go through -rc is great,
but not so much when people stop sending _everything_ and start thinking
"I'll just get it in stable in a few weeks".

For .10 I had to start making a list of "shit that's broken that there's
an outstanding patch for" and nagging people to send them week after week.
Every time I reported a new bug I'd hit, I'd have to explain I wasn't running
Linus' tree because there was so much other crap I had to carry just to
get things to a baseline of stability before starting tests.

By rc7 things got a lot better, but if we have fixes sitting around in
git trees for weeks on end with no progress, that kinda sucks.

	Dave

Re: [ 00/19] 3.10.1-stable review

[Josh Boyer]

On Thu, Jul 11, 2013 at 6:01 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> <rant>
>   I'm sitting on top of over 170 more patches that have been marked for
>   the stable releases right now that are not included in this set of
>   releases.  The fact that there are this many patches for stable stuff
>   that are waiting to be merged through the main -rc1 merge window cycle
>   is worrying to me.

Very much agreed.

>   Why are subsystem maintainers holding on to fixes that are
>   _supposedly_ affecting all users?  I mean, 21 powerpc core changes
>   that I don't see until a -rc1 merge?  It's as if developers don't
>   expect people to use a .0 release and are relying on me to get the
>   fixes they have burried in their trees out to users.  That's not that
>   nice.  6 "core" iscsi-target fixes?  That's the sign of either a
>   broken subsystem maintainer, or a lack of understanding what the
>   normal -rc kernel releases are supposed to be for.

This is the kind of stuff I was alluding to on the ksummit-discuss
list.  I was beginning to think we were the only ones noticing so I'm
glad you're speaking up.

>   So, I've picked through the patches and dug out only those that I've
>   "guessed" at being more important than others for the 3.10.1 release.
>   I'll get to the rest of these after 3.11-rc1 is out, and eventually
>   they will make it into the stable releases, but I am going to be much
>   more strict as to what is being added (carriage return changes for
>   debug messages, really ACPI developers?)

That's very much appreciated, Greg.  Thanks.

josh

[ 00/19] 3.10.1-stable review

[Greg Kroah-Hartman]

<rant>
  I'm sitting on top of over 170 more patches that have been marked for
  the stable releases right now that are not included in this set of
  releases.  The fact that there are this many patches for stable stuff
  that are waiting to be merged through the main -rc1 merge window cycle
  is worrying to me.

  Why are subsystem maintainers holding on to fixes that are
  _supposedly_ affecting all users?  I mean, 21 powerpc core changes
  that I don't see until a -rc1 merge?  It's as if developers don't
  expect people to use a .0 release and are relying on me to get the
  fixes they have burried in their trees out to users.  That's not that
  nice.  6 "core" iscsi-target fixes?  That's the sign of either a
  broken subsystem maintainer, or a lack of understanding what the
  normal -rc kernel releases are supposed to be for.

  So, I've picked through the patches and dug out only those that I've
  "guessed" at being more important than others for the 3.10.1 release.
  I'll get to the rest of these after 3.11-rc1 is out, and eventually
  they will make it into the stable releases, but I am going to be much
  more strict as to what is being added (carriage return changes for
  debug messages, really ACPI developers?)

</rant>

This is the start of the stable review cycle for the 3.10.1 release.
There are 19 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sat Jul 13 21:45:35 UTC 2013.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.1-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Linux 3.10.1-rc1

Michal Hocko <mhocko@suse.cz>
    Revert "memcg: avoid dangling reference count in creation failure"

Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    cpufreq: Fix cpufreq regression after suspend/resume

Ben Hutchings <ben@decadent.org.uk>
    SCSI: sd: Fix parsing of 'temporary ' cache mode prefix

Gleb Natapov <gleb@redhat.com>
    KVM: VMX: mark unusable segment as nonpresent

J. Bruce Fields <bfields@redhat.com>
    nfsd4: fix decoding of compounds across page boundaries

Andy Adamson <andros@netapp.com>
    NFSv4.1 end back channel session draining

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Revert "serial: 8250_pci: add support for another kind of NetMos Technology PCI 9835 Multi-I/O Controller"

Peter Hurley <peter@hurleysoftware.com>
    tty: Reset itty for other pty

Zhang Yi <wetpzy@gmail.com>
    futex: Take hugepages into account when generating futex_key

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    MAINTAINERS: add stable_kernel_rules.txt to stable maintainer information

Kees Cook <keescook@chromium.org>
    crypto: sanitize argument for format string

Kees Cook <keescook@chromium.org>
    block: do not pass disk names as format strings

Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
    hpfs: better test for errors

Kees Cook <keescook@chromium.org>
    charger-manager: Ensure event is not used as format string

Rusty Russell <rusty@rustcorp.com.au>
    module: do percpu allocation after uniqueness check. No, really!

Jonathan Salwan <jonathan.salwan@gmail.com>
    drivers/cdrom/cdrom.c: use kzalloc() for failing hardware

Josh Durgin <josh.durgin@inktank.com>
    libceph: fix invalid unsigned->signed conversion for timespec encoding

majianpeng <majianpeng@gmail.com>
    ceph: fix sleeping function called from invalid context.

Tyler Hicks <tyhicks@canonical.com>
    libceph: Fix NULL pointer dereference in auth client code


-------------

Diffstat:

 MAINTAINERS                        |  1 +
 Makefile                           |  4 ++--
 arch/x86/kvm/vmx.c                 | 11 +++++++++--
 block/genhd.c                      |  2 +-
 crypto/algapi.c                    |  3 ++-
 drivers/block/nbd.c                |  3 ++-
 drivers/cdrom/cdrom.c              |  2 +-
 drivers/cpufreq/cpufreq_stats.c    |  1 +
 drivers/power/charger-manager.c    |  2 +-
 drivers/scsi/osd/osd_uld.c         |  2 +-
 drivers/scsi/sd.c                  |  2 +-
 drivers/tty/serial/8250/8250_pci.c |  4 ----
 drivers/tty/tty_io.c               |  2 ++
 fs/ceph/xattr.c                    |  9 +++++----
 fs/hpfs/map.c                      |  3 ++-
 fs/hpfs/super.c                    |  8 +++++++-
 fs/nfs/nfs4state.c                 | 23 +++++++++++------------
 fs/nfsd/nfs4xdr.c                  |  2 +-
 include/linux/ceph/decode.h        |  5 -----
 include/linux/hugetlb.h            | 16 ++++++++++++++++
 kernel/futex.c                     |  3 ++-
 kernel/module.c                    | 34 ++++++++++++++++++----------------
 mm/hugetlb.c                       | 17 +++++++++++++++++
 mm/memcontrol.c                    |  2 --
 net/ceph/auth_none.c               |  6 ++++++
 25 files changed, 109 insertions(+), 58 deletions(-)