3 ms·

I hope someone can explain the sentiment on HN to me. I don't get it, why is this popular? I want to know how many PRs a project is getting, but more than that

I hope someone can explain the sentiment on HN to me. I don't get it, why is this popular? I want to know how many PRs a project is getting, but more than that how receptive the maintainers are. Issues don't tell the whole picture, because work gets backlogged, and you can't expect people doing this for free to have an SLA or something. but PRs.. the work is ideally at least mostly done. There is the one project for example, very popular in the industry it's used in. There is a specific use-case that I run into repeatedly, that it fails at. The project has lots of open issues (understandably), and there are multiple PRs to address that, but the maintainers give no good reason for not accepting it. I've been using some random guy's branch (who isn't even keeping up with the latest releases and backporting) for many years now, waiting for the maintainers to either reject it or accept the PR. Lots of people upvote, comment, and beg. I want to see how maintainers handle that. This is really bad. I'd prefer if they stopped reporting of issues instead of PRs. Issues is providing support, PRs let other people who fixed something or added a feature attempt to contribute. You can't just "fork it", that means you have to be the maintainer now. And how will people even find your "fork" which may have fixed things? I'd like to be able to at least find open and unmerged forks with a fix in place I could apply, even if the maintainer never got around to it. Turning PRs off is the software equivalent of hardware makers turning off support for aftermarket parts. Honestly, if you don't like PRs, ignore them like many already do. Does it look bad when you do that? Yes. As it should! Don't hide away from your preferences, own it. Let other people get access to fixes you either have no time to get to, or unwilling to implement. Just the discussions alone on security related issues (or PRs as in this case) is telling sometimes.

FeistySkink 9mo ago
So you don't want to maintain a fork, but want a maintainer to do it for free for you and wondering why that PR is not accepted? If you feel so strongly about the project popular in your 'industry', consider providing some incentive for the maintainer to care. And no, a coffee is not an incentive. Edit: this probably came off quite abrasive, but I'm getting entitled comments from users with no contributions, demanding fixes for their most ridiculously niche issues almost weekly. Like stuff doesn't build with their toolchain from 2014. Seriously? Yet, they can't be arsed to even check the fixes or follow up with basic details.
- notepad0x90 9mo ago
  It's not even about the maintainer, I can't maintain a large and complex project supported by lots of maintainers on my own, as a fork. But I can make fixes available for other users as a PR..until it's merged (or not). This is about users of the software, how will taking away PRs affect them? I'm not wondering why that PR is not accepted, maintainers have every right to ignore or reject PRs. But this discussion is about taking away the ability to even create PRs that other users of the software an discover. This is a user-hostile behavior fueled solely by laziness and pettiness.
  - FeistySkink 9mo ago
    > This is a user-hostile behavior fueled solely by laziness and pettiness. Damn, that last quip is really poisoning the well here. As a maintainer, not being paid for my projects or contributions, I have every right to decide how and if I want to accept contributions.
    - notepad0x90 9mo ago
      who said otherwise? don't accept contributions, don't review them. I already conceded your rights there. This is about preventing other people from posting PRs in the first place, not about if you accept or reject them. Two different topics.
  - duskdozer 9mo ago
    >I can't maintain a large and complex project supported by lots of maintainers on my own, as a fork Do you need to "maintain" a complex project? Why can't you just add the patches you want on your fork and update as far as it suits you? Just as the upstream doesn't have to review or accept PRs, neither do you. Users can still see the network of forks, and ime there are few that are actively updated.
    - notepad0x90 9mo ago
      How can i tell why every fork was created? How can I tell it'll fix my issue? The idea of maintaining a fork for the sake of a patch affecting only one version of the original software is silly. Not only that, others mentioned "networks" but how do users tell what I patched, diff every fork one by one? Perhaps there is a feature I don't know about since PRs just work for me.
nevon 9mo ago
You can find the forks by looking in the "network" part of the UI. I do agree that GitHub could do more to highlight forks and their relationship to one another. But I don't think the current way - having an open pull request - is the only way to do that. As a former maintainer, I am very in favor of this move. After having spent 10 years or so being hounded with "Any update on this?" and "Can we get this merged?", I don't think I would ever do it again as long as there aren't controls in place to be able to set the expectation that the code is free to do with as you will, and please go ahead and fork if you want it to do something different.
- notepad0x90 9mo ago
  Is there a way I can tell why the forks were created, like the PR description? Even if there was, I would still want to see comments/discussions both from maintainers and the community so I know i'm not applying some shady patch. I think you and others on this thread have the problem of not being able to ignore people. But that's your problem entirely. If you want a feature to silence PR notifications, by all means, I have no problem with that. You're taking out your notification annoyance by taking away a critical feature from your users. That's just petty and mean in my opinion. Heck, does your email client not have the feature to auto-sort emails to junk/deleted? Is there any frustration you have beyond that?
Lammy 9mo ago
> there are multiple PRs to address that, but the maintainers give no good reason for not accepting it. Congrats on discovering the difference between “““Open Source””” (pro-corporate; a way to socially engineer people to do work for you for free from which you can turn around and profit) and Free Software! “THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.”
- Lammy 9mo ago
  Too late to edit, but here's the inarguable truth straight from the mouth of the Open Source Initiative, that the term was the direct product of Netscape's desire to get people to work for them for free: https://opensource.org/history https://opensource.org/history “The ‘open source’ label was created at a strategy session held on February 3rd, 1998 in Palo Alto, California, shortly after the announcement of the release of the Netscape source code. […] The conferees believed the pragmatic, business-case grounds that had motivated Netscape to release their code illustrated a valuable way to engage with potential software users and developers, and convince them to create and improve source code by participating in an engaged community. The conferees also believed that it would be useful to have a single label that identified this approach and distinguished it from the philosophically- and politically-focused label ‘free software.’”
  - mnau 9mo ago
    Open source is not open contribution. There are many examples of open source, but closed contribution, e.g. SQLite. What you are listing is a business strategy of a company (free labor and advertising). Desires of a company are very different from an unpaid volunteer. In projects that leave PRs unanswered, the maintainer is already unpaid labor, but contributor want him to work on the contribution. That might not align with what maintainer wants. Edit: Personally, I find reviewing least pleasant part of dev work. Thanks to LLMs, that now also significantly more of my paid work. My desire to do code reviews in my free time is massively lower. I would rather do it myself.

FeistySkink 9mo ago

So you don't want to maintain a fork, but want a maintainer to do it for free for you and wondering why that PR is not accepted? If you feel so strongly about the project popular in your 'industry', consider providing some incentive for the maintainer to care. And no, a coffee is not an incentive. Edit: this probably came off quite abrasive, but I'm getting entitled comments from users with no contributions, demanding fixes for their most ridiculously niche issues almost weekly. Like stuff doesn't build with their toolchain from 2014. Seriously? Yet, they can't be arsed to even check the fixes or follow up with basic details.

notepad0x90 9mo ago
It's not even about the maintainer, I can't maintain a large and complex project supported by lots of maintainers on my own, as a fork. But I can make fixes available for other users as a PR..until it's merged (or not). This is about users of the software, how will taking away PRs affect them? I'm not wondering why that PR is not accepted, maintainers have every right to ignore or reject PRs. But this discussion is about taking away the ability to even create PRs that other users of the software an discover. This is a user-hostile behavior fueled solely by laziness and pettiness.
- FeistySkink 9mo ago
  > This is a user-hostile behavior fueled solely by laziness and pettiness. Damn, that last quip is really poisoning the well here. As a maintainer, not being paid for my projects or contributions, I have every right to decide how and if I want to accept contributions.
  - notepad0x90 9mo ago
    who said otherwise? don't accept contributions, don't review them. I already conceded your rights there. This is about preventing other people from posting PRs in the first place, not about if you accept or reject them. Two different topics.
- duskdozer 9mo ago
  >I can't maintain a large and complex project supported by lots of maintainers on my own, as a fork Do you need to "maintain" a complex project? Why can't you just add the patches you want on your fork and update as far as it suits you? Just as the upstream doesn't have to review or accept PRs, neither do you. Users can still see the network of forks, and ime there are few that are actively updated.
  - notepad0x90 9mo ago
    How can i tell why every fork was created? How can I tell it'll fix my issue? The idea of maintaining a fork for the sake of a patch affecting only one version of the original software is silly. Not only that, others mentioned "networks" but how do users tell what I patched, diff every fork one by one? Perhaps there is a feature I don't know about since PRs just work for me.

nevon 9mo ago

You can find the forks by looking in the "network" part of the UI. I do agree that GitHub could do more to highlight forks and their relationship to one another. But I don't think the current way - having an open pull request - is the only way to do that. As a former maintainer, I am very in favor of this move. After having spent 10 years or so being hounded with "Any update on this?" and "Can we get this merged?", I don't think I would ever do it again as long as there aren't controls in place to be able to set the expectation that the code is free to do with as you will, and please go ahead and fork if you want it to do something different.

notepad0x90 9mo ago
Is there a way I can tell why the forks were created, like the PR description? Even if there was, I would still want to see comments/discussions both from maintainers and the community so I know i'm not applying some shady patch. I think you and others on this thread have the problem of not being able to ignore people. But that's your problem entirely. If you want a feature to silence PR notifications, by all means, I have no problem with that. You're taking out your notification annoyance by taking away a critical feature from your users. That's just petty and mean in my opinion. Heck, does your email client not have the feature to auto-sort emails to junk/deleted? Is there any frustration you have beyond that?

Lammy 9mo ago

> there are multiple PRs to address that, but the maintainers give no good reason for not accepting it. Congrats on discovering the difference between “““Open Source””” (pro-corporate; a way to socially engineer people to do work for you for free from which you can turn around and profit) and Free Software! “THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.”

Lammy 9mo ago
Too late to edit, but here's the inarguable truth straight from the mouth of the Open Source Initiative, that the term was the direct product of Netscape's desire to get people to work for them for free: https://opensource.org/history https://opensource.org/history “The ‘open source’ label was created at a strategy session held on February 3rd, 1998 in Palo Alto, California, shortly after the announcement of the release of the Netscape source code. […] The conferees believed the pragmatic, business-case grounds that had motivated Netscape to release their code illustrated a valuable way to engage with potential software users and developers, and convince them to create and improve source code by participating in an engaged community. The conferees also believed that it would be useful to have a single label that identified this approach and distinguished it from the philosophically- and politically-focused label ‘free software.’”
- mnau 9mo ago
  Open source is not open contribution. There are many examples of open source, but closed contribution, e.g. SQLite. What you are listing is a business strategy of a company (free labor and advertising). Desires of a company are very different from an unpaid volunteer. In projects that leave PRs unanswered, the maintainer is already unpaid labor, but contributor want him to work on the contribution. That might not align with what maintainer wants. Edit: Personally, I find reviewing least pleasant part of dev work. Thanks to LLMs, that now also significantly more of my paid work. My desire to do code reviews in my free time is massively lower. I would rather do it myself.