3 ms·

> Can you explain why you feel rants and insults are necessary to maintain high technical standards? It is possible that they are not truly "necessary", but th

> Can you explain why you feel rants and insults are necessary to maintain high technical standards? It is possible that they are not truly "necessary", but they are one often-effective way to discourage disruptive/unproductive behaviour. Linus ultimately should not be asked to review changesets he will be far from willing to merge; and for him there are only so many hours in the day. It is, as a practical matter, necessary to communicate that there is a cost to wasting his time with work that somebody should have known was substandard, and it is important that that cost is borne primarily by the originator of that substandard work (i.e. it needs to suck more for the committer to waste Linus' time than it sucks for Linus to spend time responding). It is a high-risk, unappealing technique, but we should be careful not to impose alternatives which fail to meet the same criteria at least to some extent.

JohnBooty 8y ago
there are only so many hours [for Linus] in the day. It is, as a practical matter, necessary to communicate that there is a cost to wasting his time with work that somebody should have known was substandard This is a really a restatement of the old (yet still relevant) "Linus doesn't scale" issue, right? It's true: Linus' time is a valuable resource and shouldn't be wasted. This is of course true of any project maintainer, or any person at all really -- it's just that the stakes are a higher in the case of the Linux kernel because of the scope and impact of the project. it is important that that cost is borne primarily by the originator of that substandard work (i.e. it needs to suck more for the committer to waste Linus' time than it sucks for Linus to spend time responding) This is a nearly universal problem. Imagine suggesting "hurl insults at the perpetrators until they learn" as a solution in any other field. Ridiculous! The answer of course is to proactively reduce the number of time-wasting things that are raised to Linus' attention, not to reactively be meaner when those sorts of things do happen. Typically you'd do this in Linux or any software project by: (a) making sure that the other kernel maintainers are trusted and skilled (b) making sure that everybody has a solid understanding of what is and isn't a good contribution (c) discussing contributions ahead of time so that there are fewer surprises at review/merge time (d) solve the "Linus doesn't scale" issue by delegating more of his responsibility elsewhere, cloning him, etc. I should note that I have no idea about how the kernel maintainers function on a daily basis. Maybe they're already doing a really great job of those things, and it's only 0.001% of merge requests that result in spectacular Linus rants and therefore show up on HN or whatever. Since it seems like kernel development is humming along pretty well for the mooooooost part I'd put my money on that, but who knows.
- microcolonel 8y ago
  > I should note that I have no idea about how the kernel maintainers function on a daily basis. Maybe they're already doing a really great job of those things, and it's only 0.001% of merge requests that result in spectacular Linus rants and therefore show up on HN or whatever. Since it seems like kernel development is humming along pretty well for the mooooooost part I'd put my money on that, but who knows. Well, you're spot-on right here. The reason I think it is a more understandable solution for Linus is that, by the time a piece of substandard or dishonest work makes it to Linus, the buck should have stopped at least at a couple of places. They are doing an excellent job, but at the 99.995th percentile there is going to be a piece of substandard or dishonest work in Linus' inbox, and each time it should be a matter of considerable interest to everyone involved as to how it got there (and the multitude of ways it should not have made it).

JohnBooty 8y ago

there are only so many hours [for Linus] in the day. It is, as a practical matter, necessary to communicate that there is a cost to wasting his time with work that somebody should have known was substandard This is a really a restatement of the old (yet still relevant) "Linus doesn't scale" issue, right? It's true: Linus' time is a valuable resource and shouldn't be wasted. This is of course true of any project maintainer, or any person at all really -- it's just that the stakes are a higher in the case of the Linux kernel because of the scope and impact of the project. it is important that that cost is borne primarily by the originator of that substandard work (i.e. it needs to suck more for the committer to waste Linus' time than it sucks for Linus to spend time responding) This is a nearly universal problem. Imagine suggesting "hurl insults at the perpetrators until they learn" as a solution in any other field. Ridiculous! The answer of course is to proactively reduce the number of time-wasting things that are raised to Linus' attention, not to reactively be meaner when those sorts of things do happen. Typically you'd do this in Linux or any software project by: (a) making sure that the other kernel maintainers are trusted and skilled (b) making sure that everybody has a solid understanding of what is and isn't a good contribution (c) discussing contributions ahead of time so that there are fewer surprises at review/merge time (d) solve the "Linus doesn't scale" issue by delegating more of his responsibility elsewhere, cloning him, etc. I should note that I have no idea about how the kernel maintainers function on a daily basis. Maybe they're already doing a really great job of those things, and it's only 0.001% of merge requests that result in spectacular Linus rants and therefore show up on HN or whatever. Since it seems like kernel development is humming along pretty well for the mooooooost part I'd put my money on that, but who knows.

microcolonel 8y ago
> I should note that I have no idea about how the kernel maintainers function on a daily basis. Maybe they're already doing a really great job of those things, and it's only 0.001% of merge requests that result in spectacular Linus rants and therefore show up on HN or whatever. Since it seems like kernel development is humming along pretty well for the mooooooost part I'd put my money on that, but who knows. Well, you're spot-on right here. The reason I think it is a more understandable solution for Linus is that, by the time a piece of substandard or dishonest work makes it to Linus, the buck should have stopped at least at a couple of places. They are doing an excellent job, but at the 99.995th percentile there is going to be a piece of substandard or dishonest work in Linus' inbox, and each time it should be a matter of considerable interest to everyone involved as to how it got there (and the multitude of ways it should not have made it).