2 ms·

> Exactly. You state that reporting a bug/potential feature, or issuing a pull request, are inherently "confrontational" processes Well, don't stop there, the

• zozbot234 7y ago
  You think projects like Linux are short on maintainers and reviewers? They even have multiple maintainers for the same pieces of code, each keeping their own, preferred version of the kernel "tree". And this is an inherently-scalable process, that only needs new, prospective sub-maintainers to demonstrate good judgment in "signing off" incoming patches. Many eyes making all bugs shallow, to user a rather well-known (and relevant!) turn of phrase.
  • chx 7y ago
    > And this is an inherently-scalable process If this thread didn't already include https://lwn.net/ml/linux-fsdevel/20200217001153.GE10776@dread.disaster.area/ https://lwn.net/ml/linux-fsdevel/20200217001153.GE10776@drea... titled "FS Maintainers Don't Scale" ... from someone much, much more qualified to judge that topic than either of us unless of course you are also a kernel maintainer because the author of that email sure is. Of course this is nothing new. For example, https://opensource.com/business/16/10/linux-kernel-review https://opensource.com/business/16/10/linux-kernel-review also at https://lwn.net/Articles/703005/ https://lwn.net/Articles/703005/ http://sei.pku.edu.cn/~zhmh/linux.pdf http://sei.pku.edu.cn/~zhmh/linux.pdf is a scientific paper stating, among other things, "In summary, adding more maintainers to a file yields only a power of 1/2 increase in productivity, thus, four parallel maintainers are needed to double the overall output. This suggests limits to the scalability that can be achieved by adding multiple maintainers to the same files."
    • zozbot234 7y ago
      > also at https://lwn.net/Articles/703005/ https://lwn.net/Articles/703005/ Um, that article includes quotes stating that cautiously expanding commit rights to the submaintainer's tree can help solve this scalability problem? And the more recent email you quote says this about the underlying reason this sometimes fails (and the lead developer can't cope with incoming patch volume, thus tending to burn out in the process - this is the "can't scale" they're talking about): "...they [others] don't want to do it because they are scared of making a mistake and being yelled at by Our Mighty Leaders. That is a result of the fact that a Linux Maintainer is seen as a _powerful position_ because of the _control and influence_ it gives that person. It's also treated like an exclusive club (e.g. invite-only conferences for Maintainers) ... How many people do you know who have voluntarily given up a Maintainer position because they really didn't want to do it or they thought someone else could do a better job?" So I fail to see how contentiousness and being more confrontational than not is helping there. The linux-kernel developers are in fact doing a pretty good job of not yelling at the real newcomers (which is what most people calling for CoC's usually focus on) yet the newcomers' patches still go unreviewed. And fiddling with rules of conduct is supposed to change this for the better, how? The more you do that, the less maintainers will be inclined to renounce their formally-acknowledged influence over the project.
      • chx 7y ago
        You are constantly moving the goalposts. I have tried to challenge your position of the Linux kernel not having enough maintainers stating the maintainer system is not as scalable as you say. I even found a scientific paper studying this. You acknowledged nothing of this, rather singled out one email and spout nonsense: > So I fail to see how contentiousness and being more confrontational than not is helping there. What the hell, everything I talked about up to now is being LESS confrontational. This was my last reply, don't bother replying to me, I am not engaging further. This was a waste of my time.