3 ms·

Please read the message thread yourself, and _then_ judge: https://lore.kernel.org/linux-arm-kernel/4faa5e4c-b43b-12e4-2259-c2595bd55b97@marcan.st/T/#r65e02d194

Please read the message thread yourself, and _then_ judge: https://lore.kernel.org/linux-arm-kernel/4faa5e4c-b43b-12e4-2259-c2595bd55b97@marcan.st/T/#r65e02d19410f2f1b43ef552e97e1638c4ee4aca8 https://lore.kernel.org/linux-arm-kernel/4faa5e4c-b43b-12e4-...

smoldesu 4y ago
What is notable about this thread? Martin is proposing to replace pre-existing (functional) components of the kernel with his own contributions. The maintainers responsible for these components want to understand this implementation before merging it. Spending 2 months discussing a patch like this is not uncommon, particularly if we're talking about shot-in-the-dark implementations of undocumented hardware interfaces.
bheadmaster 4y ago
Please stop spamming. That message thread is 15 thousand lines long - it is quite disrespectful to demand I read the whole thing without even knowing what I'm looking for. Can you at least point out the relevant parts, or - even better - copy them in a comment for all to see?
- altairprime 4y ago
  This is, ironically enough, a microcosm of the post author’s complaint: people are replying to their patches without having done the due diligence of gaining context in their own first, and are offloading that burden of gaining context onto the patch author instead — which is slowly burning them out. Whether that’s appropriate or not is what ought to be discussed here; everyone takes for granted that someone else should have to “do the reading”, but that assumption doesn't scale for Linux (nor necessarily for forum discussions).
  - smoldesu 4y ago
    It's not the kernel maintainer's job to care about unsupported hardware any more than they need to worry about upstreaming the Linux fork designed to run on iPhones. This is the problem with trying to maintain community-sourced patches for complex hardware architectures; getting Linux to run on Mac is not a priority. It's not a machine designed for Linux, and Apple makes no effort to cooperate with the maintainers of the Linux kernel. If Apple (the company with ~$200,000,000,000 in cash reserves) worked with the community here, there wouldn't be any issues here.
  - bheadmaster 4y ago
    > This is, ironically enough, a microcosm of the post author’s complaint: people are replying to their patches without having done the due diligence of gaining context in their own first, and are offloading that burden of gaining context onto the patch author instead — which is slowly burning them out Eh, I get it. Understanding anything takes effort, and each one of us has a limited amount of mental energy per day. Nobody likes wasting it for what they feel is responsibility of another. I wouldn't criticize the author for what happened in the kernel discussion - I don't have enough skill or experience to understand why or how is anyone right or wrong. What I do have a problem with, is posting an article like this on HN, then shutting every comment down with "read these 15000 lines, peasant, before you even dare to speak". Most people on HN are not kernel hackers, so why the (if I may be blunt - pretentious) gatekeeping? There must be some better way of explaining why someone's comment is wrong than "here, read this large text, figure it out yourself and don't come back until you figure it out". That's just lazy and disrespectful.
    - altairprime 4y ago
      I agree, from a ringside commentary viewpoint; for general chatter on a forum, that’s too much to demand. I think that I’d have preferred a detailed analysis of the hundreds of messages for one patch broken up into segments and assigned categories. For example, and this are made up: 15% of messages stemmed from mis-application of Intel/AMD assumptions to Apple Silicon. Because doing so without naming names, in an opinionated manner, would really help make or break their point. It would also provide ground for the “read all 15,000 lines” viewpoint: either one is arguing that the assessment is improperly conducted, in which case you would need to conduct your own and provide that — or one is arguing that the assessed categorizations are not the correct ones to use, which is a separate useful debate that does not require reading all the messages.

smoldesu 4y ago

What is notable about this thread? Martin is proposing to replace pre-existing (functional) components of the kernel with his own contributions. The maintainers responsible for these components want to understand this implementation before merging it. Spending 2 months discussing a patch like this is not uncommon, particularly if we're talking about shot-in-the-dark implementations of undocumented hardware interfaces.

bheadmaster 4y ago

Please stop spamming. That message thread is 15 thousand lines long - it is quite disrespectful to demand I read the whole thing without even knowing what I'm looking for. Can you at least point out the relevant parts, or - even better - copy them in a comment for all to see?

altairprime 4y ago
This is, ironically enough, a microcosm of the post author’s complaint: people are replying to their patches without having done the due diligence of gaining context in their own first, and are offloading that burden of gaining context onto the patch author instead — which is slowly burning them out. Whether that’s appropriate or not is what ought to be discussed here; everyone takes for granted that someone else should have to “do the reading”, but that assumption doesn't scale for Linux (nor necessarily for forum discussions).
- smoldesu 4y ago
  It's not the kernel maintainer's job to care about unsupported hardware any more than they need to worry about upstreaming the Linux fork designed to run on iPhones. This is the problem with trying to maintain community-sourced patches for complex hardware architectures; getting Linux to run on Mac is not a priority. It's not a machine designed for Linux, and Apple makes no effort to cooperate with the maintainers of the Linux kernel. If Apple (the company with ~$200,000,000,000 in cash reserves) worked with the community here, there wouldn't be any issues here.
- bheadmaster 4y ago
  > This is, ironically enough, a microcosm of the post author’s complaint: people are replying to their patches without having done the due diligence of gaining context in their own first, and are offloading that burden of gaining context onto the patch author instead — which is slowly burning them out Eh, I get it. Understanding anything takes effort, and each one of us has a limited amount of mental energy per day. Nobody likes wasting it for what they feel is responsibility of another. I wouldn't criticize the author for what happened in the kernel discussion - I don't have enough skill or experience to understand why or how is anyone right or wrong. What I do have a problem with, is posting an article like this on HN, then shutting every comment down with "read these 15000 lines, peasant, before you even dare to speak". Most people on HN are not kernel hackers, so why the (if I may be blunt - pretentious) gatekeeping? There must be some better way of explaining why someone's comment is wrong than "here, read this large text, figure it out yourself and don't come back until you figure it out". That's just lazy and disrespectful.
  - altairprime 4y ago
    I agree, from a ringside commentary viewpoint; for general chatter on a forum, that’s too much to demand. I think that I’d have preferred a detailed analysis of the hundreds of messages for one patch broken up into segments and assigned categories. For example, and this are made up: 15% of messages stemmed from mis-application of Intel/AMD assumptions to Apple Silicon. Because doing so without naming names, in an opinionated manner, would really help make or break their point. It would also provide ground for the “read all 15,000 lines” viewpoint: either one is arguing that the assessment is improperly conducted, in which case you would need to conduct your own and provide that — or one is arguing that the assessed categorizations are not the correct ones to use, which is a separate useful debate that does not require reading all the messages.