(That bug was causing udev to give multiple disks the same name in /dev/disk/by-path, which I think is pretty much core udev functionality, given that udev was intended to supersede devfs.)
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.)
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".)
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.
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.
# journalctl -u ssh
I would have no problem if systemd used a database like sqlite, lmdb or anything else with some valid tooling, indexing, caching and proper recovery solutions.
Would SQLite be any more complicated than what they have now? Or OpenLDAP's Lightning Memory-Mapped Database (LMDB)? OpenLDAP/Symas' Howard Chu on the latter:
* https://www.linkedin.com/pulse/20140924071300-170035-why-you...
Also, you can pipe the output of journalctl to do whatever you want with it with those unix tools.
what tool can't you read them with? Why is the fs the fundamental unifying abstraction, as opposed to pipes?
> doesn't allow you to do all the things you can do with a real file
like what?
Also: If all pipes are files, but not all files are pipes, it would seems to me that files are more restrictive. That, and the extra steps you need to take to avoid needless IO.
that doesn't allow you to do all the things you can do with a real file
seems to me that files are more restrictive
And I've also noticed that low-level systems projects generally attract relatively few stars (i.e. a javascript library or go library will have more stars than a well used c library or systemd). My theory on that is that the people involved in projects like systemd, gnu, etc, see github as mostly just a git repository host, and don't bother with stars etc.
I guess from my perspective, I put zero weight into the stars on a project, and issue count only matters in the context of how the project deals with issues. What do you see as "worrying" in there? Do you see more value in those numbers than me?
A large number of open issues means the maintainers can't keep up. 10x more issues mean the problem is worse even if the project has 20x more stars.
If you have project A, run by a company, which uses an internal Jira instance to track backlogs and developer's selected tasks, but uses github issues to track all user's reported bugs, well, that will have fewer issues than project B, which uses github issues to track backlogs and sprints in addition to bugs.
There's a lot of variability in this. The kubernetes project (~2k issues) has a bot that closes issues after 90 days by default (~9k closed by the bot so far), and without that bot, they'd have way more.
> A large number of open issues means the maintainers can't keep up.
That's not necessarily true. Github doesn't prescribe that every issue is immediately actionable. Perhaps the issue was tagged as "feature-request / help-wanted". Perhaps it is marked as "awaiting additional reporter info" (like logs, or OS), and there's nothing the maintainers can do until the reporter gets them more info.
Whether every issue gets triaged tells you something about whether maintainers are keeping up, but issues that are triaged aren't then always closed, so the number of open issues doesn't tell you much about how many issues are triaged and how quickly.
What do you mean by "not used as intended"? systemd has a mailing list too, but they also respond to github issues. Does having multiple different forms of interaction with your community mean you're not using issues as intended?
Some projects use github issues as a sorta backlog, or in conjunction with milestones and github projects to track future work. Some don't. Are projects that don't do that not using issues as intended?
As far as I know, github gives no general guidance on how to use github issues, and it's up to each project to setup issue templates and/or contributing.md files to explain that project's expectations.
> generally shows how active, responsive and sufficiently staffed the maintainers are
Okay, so if a project has a bunch of maintainers and is so well staffed they close all issues immediately, that means they have 0 issues, so that's good, right?
Except many well-maintained projects on github have hundreds to thousands of open issues, like nodejs with >1k, rust-lang with 7k, etc.
From where I sit, how well-maintained a project is has almost nothing to do with how many issues it has. Issues are a function of number of users (which is much different from level of maintenance), and maintainer policy on whether they close issues without enough information, close stale issues automatically, use issues to track backlog work, etc.
This tells you why "low-level systems projects" attract less stars. It's because well-known, long-lasting projects attract less stars. There's a little point of starring a repo of a project that you recognize and use. You remember its name already. Meanwhile, a random JS library that looks like it could come in handy in the future? These things come and go, and you'll forget its name 5 minutes from now anyway, so you star it.