331–340 of 408 posts
Earlier quoted context omitted.
I mean, is the answer really that hard? If the "refactor" would break the interface, you can't do it. Maybe you deprecate the old method and make a new one.
How do they handle bug fixing though? What if one application wants a bug fixed, but another application is depending on the bug inadvertently?
Earlier quoted context omitted.
Simple. Contrite. To the point. No excuses, just solutions. Yeah, this is a _very_ professional response to a (typical for Linus tbh) very emotional (but correct ) post that could be easy to react emotionally to.
Fair point, but I'm coming round to the idea that emotional 'anger' might be a very effective tool to use when in charge of things. It seems well applied in this case.
There are ways to use that language without being a prick about it though. Linus does not have that ability.
Earlier quoted context omitted.
Simple. Contrite. To the point. No excuses, just solutions. Yeah, this is a _very_ professional response to a (typical for Linus tbh) very emotional (but correct ) post that could be easy to react emotionally to.
Fair point, but I'm coming round to the idea that emotional 'anger' might be a very effective tool to use when in charge of things. It seems well applied in this case.
Earlier quoted context omitted.
> John Johansen will survive. We really need to stop excusing Linus's behaviour. Just because we may happen to agree with what he is saying doesn't mean we also have to agree with how he is saying it.
> We really need to stop excusing Linus's behaviour. Just because we may happen to agree with what he is saying doesn't mean we also have to agree with how he is saying it. I couldn't agree more. More than ten years ago I was involved in the Monotone project. It was a VCS which was an ancestor to Git and a contemporary of Mercurial. That project really prioritised good conduct, and having a well functioning community…
Respect and kindness are great virtues when you're shipping widgets. If your product failing means that end-users are going to physically suffer and/or die, I don't think they're going to care one bit about those virtues or respond in kind though.
I'm not saying you can't run a big project without kindness and respect, but I'm saying that's way down the list of importance vs not harming your users. Whatever it takes to get that chief goal accomplished needs to be done. Linus' approach has clearly been working for decades now...and it especially is in this instance.
Earlier quoted context omitted.
Because high quality kernel code is more important than not alienating contributors. If someone prefers softer conduct, they are free to fork the kernel and start their own efforts.
> If someone prefers softer conduct The big issue I see people reacting to is profanity. You can be as hard on someone, given the nature of the infraction, without using profane language or denigrating someone. If they don't comply, threaten exactly what Linus threatened, no more commits will be accepted. While I don't disagree with Linus' right to speak as he does. He can be just as effective without the type of lan…
It exists and is perpetuated in a culture's lex lingua precisely because it is an effective tool.
Expletives like this cut right through rational and emotional filters to trigger exactly the kind of response Linus was looking for -- after three weeks of arguing, the guy finally realized his mistake.
Earlier quoted context omitted.
I agree that platforms should stay backward compatible as much as they can. That said, if upstream changes, sometimes you've got to change too. There should be a mechanism for releasing breaking new major versions. And it is this: 1) Release a new version for all your DIRECT dependents. Ideally they should be subscribed to your updates. 2) After they have had ample time to test it, they will release an update for THE…
If upstream changes, pick a better upstream.
Earlier quoted context omitted.
I don't see the problem with profanity, different strokes for different folks.
Profanity by itself isn't the problem. I don't have a problem with shit piss cunt fuck either. It's telling a contributor that their contributions are worthless, cannot be fixed, and other ad-hominem angry insults that just fosters a macho, jockish atmosphere in Linux that has demonstrably alienated capable contributors. I'm sorry that Sarah Sharp is no longer maintaining the USB modules because of Linus's attitude,…
Linux is a project of such a massive scale that Linus has to accept kernel commits from circles of trust in his developer community. If someone demonstrates that they don't understand the fundamental goals of the project, and their contributions are accepted largely based on trust, then yes, their contributions are effectively worthless.
They have to be moved to a further out circle and have their work filtered up through others, and you have to second guess every piece of work that they've contributed.
Earlier quoted context omitted.
In my culture we use what you'd call profanity as punctuation marks. I feel it is imperialist for people from one culture to want people from other cultures to adhere to their way of communicating.
I understand where you're coming from. It's important to take the cultures and expectations of each participant if one's goal is to communicate effectively. And that goes both ways. Both the speaker and the listener need to take this into account. If one's dogmatic, believing that requiring any change on their own part to accommodate the listener, that gets in the way of the goal of communicating effectively, just as…
Culture ownership is a thing, and Linus and team were there first. Oncomers need to adapt, or go elsewhere. They certainly don't need to provide this constant distraction.
Earlier quoted context omitted.
Just because Linus is effective at communicating what he wants doesn't mean his way is the best way. Why wouldn't it be even better if he alienated contributors less?
Because high quality kernel code is more important than not alienating contributors. If someone prefers softer conduct, they are free to fork the kernel and start their own efforts.