Was it something I said?

lseye5c8hk

7 Responses to “Was it something I said?”

  1. LGB says:

    Yes it seems many OpenBSD developers’ ego is a bit too much, not a single word from them _until_ you want to do/doubt/etc their code … 🙁

  2. JamesP says:

    Welcome to the dark side of free software

    And even though this is rarer in linux, it happens a lot

    “does funky thing” seems to me to mean “this is my driver, don’t mess with it even if you’re right”

    • roland says:

      @JamesP: Actually I don’t think the same thing could happen in Linux. If I had a patch that was ignored by a maintainer for months, I think sending it to Andrew Morton along with an explanation as detailed as the one I provided for my ral patch would end up with it getting merged. And I think that would actually work even if I weren’t a known kernel hacker. In the OpenBSD case, I actually did get email from Theo, but his answer was that only the driver owner could commit my patch.

  3. Darrin Chandler says:

    Sometimes a patch works great without exception on your system, but doesn’t work well everywhere. Without knowing details I would guess this to be the case here. Hard to tell.

    One thing I would suggest for this kind of patch is to submit a bug report using sendbug. Include how to reproduce the problem as well as the patch. The nice thing about that is there’s a ticket created, so if the dev think “yeah, I’ll get back to that” and forgets then someone will prod him about the open ticket some time. Honest.

    • roland says:

      @Darrin: I don’t necessarily expect my patch to be committed as-is. However, take a look at the original patch I linked to. I tried to describe the underlying bug in a good amount of detail, and really if you think about the interrupt handling of the driver, the bug is pretty obvious. The problem I have with the whole thing is that the “owner” of this driver never replied to any of my public postings or private emails where I described the bug, proposed a solution and asked for guidance on how to proceed. His sole contribution was to NAK my patch for vague reasons (in private email that I wasn’t copied on) when another committer finally decided to commit it.

      Also take a look at bug 5958/kernel. I don’t think reporting this bug again is going to help when the developer of the ral driver has shown no interest in debugging this over the past few years.

  4. abadidea says:

    IMHO open source projects should NEVER make decisions based on private communications. Public list/blog/tracker or it didn’t happen.

  5. florian says:

    Roland, it *can* and does.

    I’m not sure, but I think I could still produce a mail where someone from the CGL project replied to me explaining why they (at the time that i.e. included a. cox) did work on memory hotplug and these, but didn’t get around to fixing the mess that pci hotplug in linux used to be (i am not aware of its current state). in short: the maintainer let them know to stay away from his code, period.

    which is kind of funny considering
    a) they were a bunch of kernel gurus, embedded gurus and telco professionals who had experience with such features
    b) pci hotplug being not very impressive back in 2005 due to it’s lack of “WORKING”
    SuSE back then actually had a flag in rc.config called pci_hotplug_do_real_hotplug

    in the same context there was a fun email from greg kh stating that multithreaded hw init cannot work and is not worth the effort or actually impossible to implement
    that was caused on his own findings on a not-large system and feedback from a few users that ran into problems with his implementation.

    back then we daily enjoyed multithreaded and background initialisation of hardware on our hp-ux boxes with no issues and extreme gains in bootup times – notably those have many dozes of cores, dimms and sometimes over 1000 visible luns.

    what i’m trying to say is: there are ego issues, most probably in almost all projects.
    half of the time people will try to push their own ideas without listening, and the other half of the times the other people will not listen to someone elses ideas.

    Did you happen to read the sociology study on the samba project?
    I think in OSS we need to learn to be more aware of how social factors influence our interactions…

    … so we can better concentrate on hacking and being anti-social 😉