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).
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.