7 ms·

What particularly grated was that they managed to introduce bugs into udev and then say they didn't have the "expertise or understanding" to fix them: https://g

What particularly grated was that they managed to introduce bugs into udev and then say they didn't have the "expertise or understanding" to fix them: https://github.com/systemd/systemd/issues/7157#issuecomment-338482132 https://github.com/systemd/systemd/issues/7157#issuecomment-... (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.)

867-5309 5y ago
the systemd stars-to-issues ratio is worrying to say the least
- Iolaum 5y ago
  lolz - i 'll be keeping an eye on that from now on :) (on some of my fav projects)
- TheDong 5y ago
  What do you imagine that ratio shows? Different projects use issues differently, so that number isn't super comparable... 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?
  - 867-5309 5y ago
    I think it generally shows how active, responsive and sufficiently staffed the maintainers are. should projects be on github if the issues aren't used as intended? the worry comes from the number of systems in production relying on systemd
    - pseudalopex 5y ago
      More stars wouldn't decrease the number of issues though.
      - 867-5309 5y ago
        it would decrease the ratio
        pseudalopex 5y ago
        The number of issues has some relevance. The number of stars doesn't.
        867-5309 5y ago
        not following
        pseudalopex 5y ago
        You can't compare the number of stars for different kinds of software. 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.
        TheDong 5y ago
        For what it's worth, I also don't think comparing issues between different projects works. 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.
  - TeMPOraL 5y ago
    Github stars are just bookmarks. They're not an expression that someone loves the project, or are using it, or even very interested in it - they're just a way to bookmark something that piqued your interest, so that you can find it later. 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.
    - saagarjha 5y ago
      Well, to you. I use GitHub stars as a way to mark projects that I use or particularly appreciate.
zxzax 5y ago
I'm just curious, how would you suggest they debug and maintain support for that hardware, without even owning that particular device? It seems like anything they do would just be a wild guess as to whether it actually works or not. In my experience with this specialized datacenter hardware, if people want any of this stuff fixed (in userspace or in the kernel) it usually falls on the hardware vendor to hire some developers to fix it and upstream it, or at the very least donate some hardware to the upstream project so they can test properly.
- mjw1007 5y ago
  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".)

867-5309 5y ago

the systemd stars-to-issues ratio is worrying to say the least

Iolaum 5y ago
lolz - i 'll be keeping an eye on that from now on :) (on some of my fav projects)
TheDong 5y ago
What do you imagine that ratio shows? Different projects use issues differently, so that number isn't super comparable... 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?
- 867-5309 5y ago
  I think it generally shows how active, responsive and sufficiently staffed the maintainers are. should projects be on github if the issues aren't used as intended? the worry comes from the number of systems in production relying on systemd
  - pseudalopex 5y ago
    More stars wouldn't decrease the number of issues though.
    - 867-5309 5y ago
      it would decrease the ratio
      - pseudalopex 5y ago
        The number of issues has some relevance. The number of stars doesn't.
        867-5309 5y ago
        not following
        pseudalopex 5y ago
        You can't compare the number of stars for different kinds of software. 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.
        TheDong 5y ago
        For what it's worth, I also don't think comparing issues between different projects works. 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.
- TeMPOraL 5y ago
  Github stars are just bookmarks. They're not an expression that someone loves the project, or are using it, or even very interested in it - they're just a way to bookmark something that piqued your interest, so that you can find it later. 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.
  - saagarjha 5y ago
    Well, to you. I use GitHub stars as a way to mark projects that I use or particularly appreciate.

zxzax 5y ago

I'm just curious, how would you suggest they debug and maintain support for that hardware, without even owning that particular device? It seems like anything they do would just be a wild guess as to whether it actually works or not. In my experience with this specialized datacenter hardware, if people want any of this stuff fixed (in userspace or in the kernel) it usually falls on the hardware vendor to hire some developers to fix it and upstream it, or at the very least donate some hardware to the upstream project so they can test properly.

mjw1007 5y ago
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".)