On kernel mailing list behavior [LWN.net]

On kernel mailing list behavior

Posted Jul 19, 2013 12:14 UTC (Fri) by tytso (✭ supporter ✭, #9993)
In reply to: On kernel mailing list behavior by daniel
Parent article: On kernel mailing list behavior

The htree code was significantly cleaned up before it got merged -- by me. That was a special case, though. because we very much wanted the feature, and it was clear you wouldn't do it. If you think what is there now isn't great, it was ten times worse before I was done getting it to the point where I was comfortable putting the changes into mainline.

It is *not* the maintainer's responsibility to clean up, rewrite, and merge in every single code submission. That just doesn't scale. There have been features that have never made it into ext4 simply because the submitter couldn't get the code cleaned up enough.

Also, for the record, I am not paid to the ext4 maintainer. Google is kind enough to let me spend a certain amount of my time on it --- but it's not what pays my salary. And my hats are off to many of the other ext4 contributors who go above and beyond what is strictly needed "for their company", but who then make their code contributions clean enough and general enough that it is fit for the upstream kernel.

to post comments

On kernel mailing list behavior

Posted Jul 19, 2013 18:57 UTC (Fri) by daniel (guest, #3181) [Link] (15 responses)

My advice to you, Ted, is that if your Google manager ever states that working on Ext4 is not part of your job description, you should leave for a more enlightened employer. Obviously, there are many who would be happy to have you.

Thanks for "cleaning up" HTree to your taste. Bear in mind that it might not have been to my taste. And indeed, I have issues with the taste in that code myself, but curiously, my issues seem to be completely different ones than your issues. Moral of the story: taste is a subjective thing.

One thing is abundantly clear, and we should get this straight: maintainers should not be assigning make-work projects to active contributors. It is a most excellent way to turn an active contributor into an ex-contributor. Instead, try to use other means at your disposal. For example, put an intern on it. I know you can.

Ted, you may not realize it but you are perpetuating the toxic culture in several ways right now:

1) You should not have been harassing me about cosmetic changes at any time, and you should not be justifying it now. If a polite suggestion results in me going in and making a series of cosmetic changes to bring the code up to "kernel standard" (whatever that is, the kernel is full of ugly code written by the same people who complain about ugliness in the code of others) then fine. Everybody happy. But harassment - and that is exactly what it was - is way over the top.

2) You should politely let this particular matter drop instead of dragging it on forever and confirming to the world that the rumoured toxic culture does in fact exist.

3) You should avoid fomenting tension in public amongst community members who are supposed to be setting an example. Please email me privately if you want to continue this thread, otherwise, beer is on me at the next meet up.

4) Mobbing. That is the technical term for it. Recognize and actively defuse, whether it happens in your own thread or somebody else's.

By the way, what about those patches from Andreas? As I understand it, they do clean up some substantive issues, such as the arbitrary limitation to two level trees.

On kernel mailing list behavior

Posted Jul 19, 2013 20:12 UTC (Fri) by dlang (guest, #313) [Link] (12 responses)

> maintainers should not be assigning make-work projects to active contributors.

one person's "make-work" project is another persons "critical for long term maintainability" project.

It's _very_ common for people to some to an open-source project and hand over a bunch of code to be implemented.

It's almost unheard of for the same person to be involved a decade later to fix or clarify that same code.

As a result, the maintainers (many of who _have_ been around for a long time) are FAR more concerned about maintainability issues than new contributers.

Sometimes the maintainer will do the work to convert a contribution to be more maintainable, but as Ted notes, that doesn't scale. What the maintainer needs to do is to push back on the contributer to get them to improve the submission.

In most cases, the contributer does so, and their next contribution is better (requiring less change).

Sometimes, the maintainer will ask the contributer to fix something else that the contributer sees as related to the contribution. sometimes the contributer does so and the result is much better, sometimes the contributer doesn't do so and their change goes in anyway, and other times the contributer refuses and goes away, and their change doesn't go in. All of these are acceptable results

On kernel mailing list behavior

Posted Jul 20, 2013 7:52 UTC (Sat) by daniel (guest, #3181) [Link] (11 responses)

You are being rather presumptuous, assuming that Ted's cleanups were critical for long term maintainability.

I will give you this: Ted's legendary hack to make telldir/seekdir work was if fact critical for long term usage of HTree, or even short term usage. But I have always said that, haven't I. Now maybe you should go read Ted's telldir code, then come here and tell me more of your theories about long term maintainability. Dare you.

By the way, did you see the rule 4 above, no mobbing? Please think about how you might have worded your comment so that it does not come across as a defence of the right to abuse/harass/whatever toxic behavior LKML has earned a reputation for.

On kernel mailing list behavior

Posted Jul 20, 2013 8:20 UTC (Sat) by dlang (guest, #313) [Link] (9 responses)

you made up those rules, I never agreed to them.

By your definition, anyone who argues with you is now guilty of 'mobbing' and violating the rules. This is exactly the type of rules gamesmanship that makes people very reluctant to allow any formal rules to be defined.

As for maintainability, where there is disagreement between contributors and existing long-term maintainers (especially when there are multiple maintainers talking), the maintainers get the benefit of the doubt. They have earned it over time.

In programming and system administration, people come into existing situations and always blame the prior person for the problems they see, and for that person being short-sighted.

When a person stays in a job long enough, they look at something and have the same reaction, but then realize that they were the one responsible, and they can remember why they did things that way. After a few times of this, they get MUCH more careful about what they are willing to accept, because they realize that they will have to maintain it over the long term.

Until you've been on something long enough to be in the position of replacing your original work with the next generation (and seeing the next generation of co-workers and their reaction to your prior work), youreally don't think about maintainability in the same way.

In my case, it's system and network administration and design, for Linus and his Lieutenants, it's maintainability of the kernel code. There are a LOT of things that they did 15 years ago that they would not accept from anyone today

On kernel mailing list behavior

Posted Jul 20, 2013 8:32 UTC (Sat) by daniel (guest, #3181) [Link] (8 responses)

Feh. You are just sticking up for the current toxic culture, including mobbing. Let Ted argue his own points please. Oh wait, it was Al. Oh wait, it's a mob, including you.

Your post is full of fallacies but we already wasted enough bandwidth on this, you find them please.

On kernel mailing list behavior

Posted Jul 20, 2013 8:39 UTC (Sat) by dlang (guest, #313) [Link] (7 responses)

I actually expected you to dismiss anything that I said.

i also expect that you will dismiss anything that Ted says.

After all, anyone who doesn't agree with you must be blindly in favour of abusing people.

On kernel mailing list behavior

Posted Jul 20, 2013 8:53 UTC (Sat) by daniel (guest, #3181) [Link] (5 responses)

You posted a patronizing lecture, proceeding from an assumption that is dubious at best. Your behaviour is toxic, and you react defensively to that being pointed out, rather than doing the right thing and considering how you might become part of the solution instead of part of the problem. By the way, you never said thank you. Good night.

On kernel mailing list behavior

Posted Jul 20, 2013 13:47 UTC (Sat) by shmget (guest, #58347) [Link] (4 responses)

" Your behaviour is toxic, and you react defensively to that being pointed out, rather than doing the right thing and considering how you might become part of the solution instead of part of the problem"

Have you ever hear of that wonderful technical invention called : 'The mirror'.
you should try it one day, dear kettle.

On kernel mailing list behavior

Posted Jul 20, 2013 20:35 UTC (Sat) by daniel (guest, #3181) [Link] (3 responses)

Your behaviour is called "blaming the victim". Part of the toxic pattern.

On kernel mailing list behavior

Posted Jul 20, 2013 20:39 UTC (Sat) by daniel (guest, #3181) [Link] (2 responses)

And further, you joined in the mobbing. And also forgot to say thank you. Time to go get that mirror out.

By the way, what is your real name? Are you a kernel developer?

On kernel mailing list behavior

Posted Jul 21, 2013 0:33 UTC (Sun) by bronson (subscriber, #4806) [Link] (1 responses)

Please just stop.

On kernel mailing list behavior

Posted Jul 21, 2013 2:35 UTC (Sun) by daniel (guest, #3181) [Link]

Et tu Bronson?

On kernel mailing list behavior

Posted Jul 22, 2013 20:05 UTC (Mon) by Baylink (guest, #755) [Link]

I've seen the behaviour Daniel is exhibiting here, before, here on LWN.

It was aimed at me, a couple years ago, in a thread also prominent for pointing me to Derailing For Dummies to acquire an education in how not to do ... something I wasn't doing in the first place.

Old timers will remember the thread; *EVERYONE* is invited not to, um, derail *this* thread into that one.

On kernel mailing list behavior

Posted Jul 20, 2013 13:44 UTC (Sat) by shmget (guest, #58347) [Link]

"By the way, did you see the rule 4 above, no mobbing?"
Now who's being presumptuous ?

"your comment so that it does not come across as a defence of the right to abuse/harass/whatever toxic behavior LKML "
Nice begging the question fallacy... but the point has not being conceded, no matter how much creative you choose to be with your vocabulary to try to pain a favorable picture of your position.

On kernel mailing list behavior

Posted Jul 20, 2013 18:25 UTC (Sat) by tytso (✭ supporter ✭, #9993) [Link] (1 responses)

The cleanup I was referring to wasn't the telldir/seekdir hack, but the fact that the code was deeply nested with huge numbers of goto commands. I fixed it by refactoring the code and adding some functions, so the flow of control was more understandable. I don't consider such changes to be "cosmetic" by the way; that would be changing the names of variables, cleaning up english/spelling mistakes, fixing whitespace. And I do a certain amount of that too. The changes I was referring to, and the problems which Al alluded to, were not cosmetic problems, but things which are fundamental to the code's long-term maintainability.

People who are curious what the difference might be are invited to look at the your original code submission, and compare and contrast that to with is in ext3 and ext4 today.

On kernel mailing list behavior

Posted Jul 21, 2013 20:26 UTC (Sun) by daniel (guest, #3181) [Link]

I know that Ted, and that can be plainly seen from my post. You should also realize that I consider your "cleanups" purely cosmetic, however I would never dream of claiming that you should not have done it. It made you happy, you see. It was pointless to me, since I regarded the original as well within the bounds of what any professional ought to be able to read without effort.

Maybe I am wrong about that. However if you want to see a lot of long functions, go read the FreeBSD code. Same type of subsystem. Multi-hundred like functions everywhere you look. They like it that way. I like it either way: I am generally more concerned about the substance.

Taste is very much subjective. If you want to exercise yours in the subsystem you maintain, then by all means do so. That is your business, not mine. If you do exercise your taste, you can do so in a polite way.

Anyway, it is clear that we differ. I am saying, clearly cosmetic, you are saying fundamental. Well, the great thing is, you were able to change it so you were happy. Why you were berating me then, and still are now, is beyond me. Now we as a community have put a word to such behaviour: toxic. And you are not by any means a prominent offender. This is a great time to sit back, take a deep breath, and ask yourself why you felt compelled to act that way, and why you feel compelled to defend it now. I am telling you it is harmful and hurtful, you respond by doing it more. It is not even the real you, this is something more akin to road rage, the main difference being "behind a keyboard" as opposed to "behind a steering wheel".