4 ms·

If they felt they needed information from, say, the Linux scsi maintainers then they could have gone out and asked for it. If they thought that in order for ude

If they felt they needed information from, say, the Linux scsi maintainers then they could have gone out and asked for it. If they thought that in order for udev to do a proper job with these devices they needed the sg3-utils maintainers to write something new, they could have gone and asked for that. As it was they just stuck a "needs-new-home" label on the bug and ignored it. I think useful action would have been more likely if udev had still been maintained by a team who believed they'd taken on the responsibility to make /dev/disk/by-path work, rather than maintained as a small part of a project whose maintainers are mostly interested in other things. (Also, IIRC from what I had to do to work around it, they could have fixed that bug by reverting the change that introduced it. It wasn't a case of existing udev code not working with new hardware; it was caused by someone making changes without understanding the consequences.)

zxzax 5y ago
That's what I mean though, all of that seems to be just wild guessing as to what will actually work and sending random emails out to random people who may or may not be able to fix it (Disclaimer: I don't know anything about this specific bug or the specific hardware). Wouldn't someone who actually owns the device and knows who to contact on the kernel side be a better person to lead the effort on that?
- mjw1007 5y ago
  This was a bug in udev. The right people to lead the effort on fixing bugs in udev are the udev maintainers. If people did not wish to have the responsibility for leading the effort to fix bugs in udev, they had the option of not taking over the maintenance of udev. I agree with ohazi, above, that the world would be a better place if the systemd people had availed themselves of that option. (To be fair, it looks like this issue was fixed a few months later by someone who knew what they were doing. So the main lesson here may be something more like "@poettering should not be triaging udev bugs".)
  - zxzax 5y ago
    I see people saying this kind of thing often in open source and I think you are missing the point here: who is going to fix this bug? You can say systemd developers shouldn't triage it, and then you're left with nobody to triage the bug at all. So what will you do? The point is, they don't own the hardware, they can't fix the bug. You have to find somebody who actually does own the hardware who knows what is going on, which seems to be exactly what happened. But if you get unlucky and if zero of those people are contributing to udev or any of its forks, then the bug probably won't ever get fixed.
    - 3np 5y ago
      I think their point is: with smaller project scope, this bug wouldn’t have existed in the first place.
      - zxzax 5y ago
        That is throwing the baby out with the bathwater though, people who want large scale projects will continue to make projects with large scopes.
        regularfry 5y ago
        And they will continue to be bitten by problems specific to large-scope projects. Wanting something, no matter how much, does not let them escape engineering reality.
        zxzax 5y ago
        I think they are aware of what they signed up for. Linux has continued to grow year after year, the reality for them is that they can afford it.
        regularfry 5y ago
        Apparently not. If they had not signed up for it, in this case they would not have ended up triaging a bug they did not have the skills or hardware to tackle.

zxzax 5y ago

That's what I mean though, all of that seems to be just wild guessing as to what will actually work and sending random emails out to random people who may or may not be able to fix it (Disclaimer: I don't know anything about this specific bug or the specific hardware). Wouldn't someone who actually owns the device and knows who to contact on the kernel side be a better person to lead the effort on that?

mjw1007 5y ago
This was a bug in udev. The right people to lead the effort on fixing bugs in udev are the udev maintainers. If people did not wish to have the responsibility for leading the effort to fix bugs in udev, they had the option of not taking over the maintenance of udev. I agree with ohazi, above, that the world would be a better place if the systemd people had availed themselves of that option. (To be fair, it looks like this issue was fixed a few months later by someone who knew what they were doing. So the main lesson here may be something more like "@poettering should not be triaging udev bugs".)
- zxzax 5y ago
  I see people saying this kind of thing often in open source and I think you are missing the point here: who is going to fix this bug? You can say systemd developers shouldn't triage it, and then you're left with nobody to triage the bug at all. So what will you do? The point is, they don't own the hardware, they can't fix the bug. You have to find somebody who actually does own the hardware who knows what is going on, which seems to be exactly what happened. But if you get unlucky and if zero of those people are contributing to udev or any of its forks, then the bug probably won't ever get fixed.
  - 3np 5y ago
    I think their point is: with smaller project scope, this bug wouldn’t have existed in the first place.
    - zxzax 5y ago
      That is throwing the baby out with the bathwater though, people who want large scale projects will continue to make projects with large scopes.
      - regularfry 5y ago
        And they will continue to be bitten by problems specific to large-scope projects. Wanting something, no matter how much, does not let them escape engineering reality.
        zxzax 5y ago
        I think they are aware of what they signed up for. Linux has continued to grow year after year, the reality for them is that they can afford it.
        regularfry 5y ago
        Apparently not. If they had not signed up for it, in this case they would not have ended up triaging a bug they did not have the skills or hardware to tackle.