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?
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".)
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.
For what it's worth, I didn't mean that the systemd people shouldn't triage the bug.
I meant that I suspect @poettering was mistaken when he said the current maintainers didn't collectively have "the expertise and understanding to maintain this properly."
As far as I can make out, there was nothing particularly hardware-specific about the bug. The bug was that udev was assuming that there could be no more than one disk per SATA host node, which turns out not to be the case.
`udevadm info` output would have been enough to see what was going on, which I'm sure the reporter would have happily supplied.
From what you were saying earlier, from the perspective of the bug triager, it sounds like there were multiple areas that maybe this could have been fixed in, not necessarily udev. So still that comes back to: the correct people to triage that bug really would have been the distro maintainers, who have total visibility over the whole system and who are better equipped to pinpoint where the bug should be fixed. And then from there they can pass it off to a systemd person or an OEM person, or both, or whatever (Again disclaimer, I don't know anything about this particular SATA hardware or whether this is normal behavior for a host node, this is just my experience from trying to triage this type of bug).
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.
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.
Just to be clear: the alternative there is that nobody looks at the bug at all because nobody but the bug reporter has the hardware. I don't think that's what you want, I assume you would just prefer the bug to be fixed.
No, the alternative is that, with no clear owner of the bug, the ownership problem gets dealt with early, rather than having the bug go stale in a can't-fix-won't-fix state for months because the wrong people claimed ownership of the subsystem.
>the wrong people claimed ownership of the subsystem
That's... not what's happening at all? The issue is there _wasn't_ any of the right people around to claim ownership of the bug. It's not like someone in the know can't just look at the systemd bug tracker, it's all public. Like, I get what your complaint is, but at the end of the day, do you really care who's name is on the commit that fixes the bug? I usually don't, and most maintainers I know probably don't either -- they're usually happy to delegate to someone who's more knowledgeable in the problem area. If you have some other solution you'd like to suggest here then I'd love to hear it, let's move beyond the criticism and start thinking about solutions. And I don't even mean this as a solution in systemd, I mean this as a "helps anything that interacts with hardware and has bugs that could potentially be caused by hardware" solution.
This wasn't a hardware bug and it didn't materialize only when some particular hardware was plugged in. Were they just supposed to open a phone book, pick a random hard drive manufacturer, and say "hey this is your problem now"?
