3 ms·

If updates are assuming they don’t have to support whatever those peculiarities are, won’t the support burden be massive? As opposed to starting in a supported

If updates are assuming they don’t have to support whatever those peculiarities are, won’t the support burden be massive? As opposed to starting in a supported state and enforcing a policy of not breaking existing support (until it’s so disused no one complains). Who decides what degree of “popularity” is sufficient to maintain default support?

CJefferson 4y ago
The problem is, I find I never get lovely clean patches, I just get GitHub PRs that day "hey, your code doesn't work on my weird CPU", or get a patch that fixes KettleBSD which breaks Cygwin on windows (which we care much more about supporting). I don't think anyone is complaining about well written fully functioning patches, that break no existing features or OSes.
- Hackbraten 4y ago
  > I don't think anyone is complaining about well written fully functioning patches, that break no existing features or OSes. While most wouldn’t be complaining, I think any maintainer should absolutely feel free to refuse a well-written, fully working patch for any reason. For example, that patch may be too large or too complex, thus might become a liability at some point in the future. Maybe managing user expectations is a priority for the maintainer. Maybe they wish to reduce support burden because they’d like spend more time with their family. All that should be deemed normal and acceptable. It can feel disappointing (numerous pull requests that I wrote have been denied or ignored), but I think it’s important that we, as a community, normalize that.
- johnklos 4y ago
  I think part of this could be fixed if Github, which seems to be the most used, lowest common denominator, had bug report mechanisms that were the equivalent of: "This bug report has been reviewed and can't continue without more information. This report is now considered inactive unless you do these prescribed actions and report back with this specific information. Click here to submit this specific information."
  - Hackbraten 4y ago
    Some projects seem to be assigning labels such as `needs-response` or `awaiting-user-response`, and have a bot in place that closes the issue if it gets stale.
Hackbraten 4y ago
> Who decides what degree of “popularity” is sufficient to maintain default support? Each upstream project and upstream distro is responsible for deciding on such a policy for themselves. Many upstream distros do just that already with their packaging. For example, you may not find a Linux kernel image that will work on your Pentium III CPU on Debian’s main repositories. Or an OpenSSL binary package. Such decisions are highly arbitrary and at the discretion of the people who do the maintenance work and pay the hosting bills. Being able to draw the line somewhere is a feature. It can help keep maintainers from burning out or giving up under the load of support requests. Given the situation of a specific project, its individual goals, and the people involved, I would expect their decision to take into account many more factors than just the “so disused that no one complains” axis.

CJefferson 4y ago

The problem is, I find I never get lovely clean patches, I just get GitHub PRs that day "hey, your code doesn't work on my weird CPU", or get a patch that fixes KettleBSD which breaks Cygwin on windows (which we care much more about supporting). I don't think anyone is complaining about well written fully functioning patches, that break no existing features or OSes.

Hackbraten 4y ago
> I don't think anyone is complaining about well written fully functioning patches, that break no existing features or OSes. While most wouldn’t be complaining, I think any maintainer should absolutely feel free to refuse a well-written, fully working patch for any reason. For example, that patch may be too large or too complex, thus might become a liability at some point in the future. Maybe managing user expectations is a priority for the maintainer. Maybe they wish to reduce support burden because they’d like spend more time with their family. All that should be deemed normal and acceptable. It can feel disappointing (numerous pull requests that I wrote have been denied or ignored), but I think it’s important that we, as a community, normalize that.
johnklos 4y ago
I think part of this could be fixed if Github, which seems to be the most used, lowest common denominator, had bug report mechanisms that were the equivalent of: "This bug report has been reviewed and can't continue without more information. This report is now considered inactive unless you do these prescribed actions and report back with this specific information. Click here to submit this specific information."
- Hackbraten 4y ago
  Some projects seem to be assigning labels such as `needs-response` or `awaiting-user-response`, and have a bot in place that closes the issue if it gets stale.

Hackbraten 4y ago

> Who decides what degree of “popularity” is sufficient to maintain default support? Each upstream project and upstream distro is responsible for deciding on such a policy for themselves. Many upstream distros do just that already with their packaging. For example, you may not find a Linux kernel image that will work on your Pentium III CPU on Debian’s main repositories. Or an OpenSSL binary package. Such decisions are highly arbitrary and at the discretion of the people who do the maintenance work and pay the hosting bills. Being able to draw the line somewhere is a feature. It can help keep maintainers from burning out or giving up under the load of support requests. Given the situation of a specific project, its individual goals, and the people involved, I would expect their decision to take into account many more factors than just the “so disused that no one complains” axis.