7 ms·

> If there was one thing I wish I could change about user behaviour, it would be this. Speaking from a user perspective, I don't think that would be wise. If d

> If there was one thing I wish I could change about user behaviour, it would be this. Speaking from a user perspective, I don't think that would be wise. If distributions would just stop feature patching, things would be a lot simpler. I mean, if a feature is good, everyone should have it, not just the users of one distribution. So please submit the patch upstream, discuss it and wait for the next release. That way, there is no real problem when users submit to upstream bug-trackers. The only exception is (time-critical) security patching. But those patches should be removed again as soon as upstream solves the issue. The scenario you are wishing for looks like an obvious solution to the issues you are having but will just make everything worse in the long run (slow and fragmented).

jiggunjer 7y ago
Are there any distros with a strict upstream-only policy?
- deleted 7y ago
  [deleted]
- kashyapc 7y ago
  Fedora comes very close. But I'm biased, as a user of (and contributor to) it for about ten years. Don't take my word for it, read the related documentation[1]: "The Fedora Project focuses, as much as possible, on not deviating from upstream in the software it includes in the repository. The following guidelines are a general set of best practices, and provide reasons why this is a good idea, tips for sending your patches upstream, and potential exceptions Fedora might make. The primary goal is to share the benefits of a common codebase for end users and developers while simultaneously reducing unnecessary maintenance efforts." The linked[1] documentation also answers, with specific examples, the question of: "What are deviations from upstream?" [1] https://fedoraproject.org/wiki/Staying_close_to_upstream_projects https://fedoraproject.org/wiki/Staying_close_to_upstream_pro...
- majewsky 7y ago
  https://www.archlinux.org/about/ https://www.archlinux.org/about/ > Arch [Linux] strives to keep its packages as close to the original upstream software as possible. Patches are applied only when necessary to ensure an application compiles and runs correctly with the other packages installed on an up-to-date Arch system.
- megous 7y ago
  I doubt it. It's unreasonable. "Upstream first, patch it if that fails" is good enough. There are widely used packages that did not have release in 5 years and distros have to carry around patches just to make them compile with openssl 1.1, or fix known CVEs, or whatever.
  - cyphar 7y ago
    This is the correct answer. Distributions don't apply patches just for the sake of it or because we enjoy it -- it makes packaging more annoying for us when we have to rebase patches each version bump. But sometimes it's necessary and it would be a silly limitation to not allow yourself to patch software which is under a license that explicitly gives you permission to modify it. I would argue any rolling-release or bleeding-edge distribution is pretty much the closest you'll get to "pure upstream". Stable distributions have more patches by necessity, and enterprise distributions even more so.
- Mediterraneo10 7y ago
  Slackware prefers not to make changes to the upstream version.
  - peterwwillis 7y ago
    Specifically, Slack patches to get software to build, because often software will work for the original developer, but not with a different set of dependencies. Otherwise everything else stays default. I think this is the closest anyone can reasonably get to strict-upstream and still have stable releases.
cyphar 7y ago
I am an upstream maintainer of quite a few projects as well as a downstream maintainer of quite a few packages, so I've seen this from both sides of the exchange. Sometimes the user-facing issue isn't an actual patch, it's the default configuration (which might be distribution-specific) or any other host of non-code changes (default security policy and so on). These things should be reported to the distribution, but often get reported upstream which acts as spam. And note that most downstream patches are backported bugfixes, not feature patches -- in my experience those are the exception. > So please submit the patch upstream, discuss it and wait for the next release. What if you're being paid for support and a customer needs a fix which you need to backport (it's not a CVE but it's a serious issue)? This is the problem we find ourselves in very often, and is why we push patches upstream but also patch our downstream packages so that the issue is resolved for our users. Some projects have release life-cycles that are ~6 months apart -- how do you explain to users that they need to wait 6 months in order for a fix which is already written and merged to be shipped to them? If we only ship it to those customers then it's not fair to the rest of our users nor the rest of the community (this is why SUSE has a Factory-first policy where all SLE changes must land in openSUSE first). And finally (in rare cases) the upstream might not accept patches that are required in order for some distribution features to work because they fundamentally disagree with the feature. What are we supposed to do in those cases? Either way, someone will complain because the best solution (merge it upstream) is closed off. While it would be ideal if downstream patching was unnecessary, that's not the world we live in. Again, I do submit patches upstream religiously -- but it's not as cut-and-dry as you might think.
- pg_bot 7y ago
  Fork the project, prefix the command with your company name and tell them to use that command with the patch applied if they need it today. This solves all your problems.
  - cyphar 7y ago
    I think you're over-estimating how many users are willing to change their workflow or scripts to accommodate things like this. They will switch away from your distribution to one which patches the actual package. I also don't agree this would result in fewer upstream bug reports -- "suse-foobar" will still result in bug reports for "foobar" (I've seen some cases of this happening). You'd need to rename the project entirely so that users don't know what the upstream GitHub repo is, and that's even more anti-community than any other suggestion.

jiggunjer 7y ago

Are there any distros with a strict upstream-only policy?

deleted 7y ago
[deleted]
kashyapc 7y ago
Fedora comes very close. But I'm biased, as a user of (and contributor to) it for about ten years. Don't take my word for it, read the related documentation[1]: "The Fedora Project focuses, as much as possible, on not deviating from upstream in the software it includes in the repository. The following guidelines are a general set of best practices, and provide reasons why this is a good idea, tips for sending your patches upstream, and potential exceptions Fedora might make. The primary goal is to share the benefits of a common codebase for end users and developers while simultaneously reducing unnecessary maintenance efforts." The linked[1] documentation also answers, with specific examples, the question of: "What are deviations from upstream?" [1] https://fedoraproject.org/wiki/Staying_close_to_upstream_projects https://fedoraproject.org/wiki/Staying_close_to_upstream_pro...
majewsky 7y ago
https://www.archlinux.org/about/ https://www.archlinux.org/about/ > Arch [Linux] strives to keep its packages as close to the original upstream software as possible. Patches are applied only when necessary to ensure an application compiles and runs correctly with the other packages installed on an up-to-date Arch system.
megous 7y ago
I doubt it. It's unreasonable. "Upstream first, patch it if that fails" is good enough. There are widely used packages that did not have release in 5 years and distros have to carry around patches just to make them compile with openssl 1.1, or fix known CVEs, or whatever.
- cyphar 7y ago
  This is the correct answer. Distributions don't apply patches just for the sake of it or because we enjoy it -- it makes packaging more annoying for us when we have to rebase patches each version bump. But sometimes it's necessary and it would be a silly limitation to not allow yourself to patch software which is under a license that explicitly gives you permission to modify it. I would argue any rolling-release or bleeding-edge distribution is pretty much the closest you'll get to "pure upstream". Stable distributions have more patches by necessity, and enterprise distributions even more so.
Mediterraneo10 7y ago
Slackware prefers not to make changes to the upstream version.
- peterwwillis 7y ago
  Specifically, Slack patches to get software to build, because often software will work for the original developer, but not with a different set of dependencies. Otherwise everything else stays default. I think this is the closest anyone can reasonably get to strict-upstream and still have stable releases.

cyphar 7y ago

I am an upstream maintainer of quite a few projects as well as a downstream maintainer of quite a few packages, so I've seen this from both sides of the exchange. Sometimes the user-facing issue isn't an actual patch, it's the default configuration (which might be distribution-specific) or any other host of non-code changes (default security policy and so on). These things should be reported to the distribution, but often get reported upstream which acts as spam. And note that most downstream patches are backported bugfixes, not feature patches -- in my experience those are the exception. > So please submit the patch upstream, discuss it and wait for the next release. What if you're being paid for support and a customer needs a fix which you need to backport (it's not a CVE but it's a serious issue)? This is the problem we find ourselves in very often, and is why we push patches upstream but also patch our downstream packages so that the issue is resolved for our users. Some projects have release life-cycles that are ~6 months apart -- how do you explain to users that they need to wait 6 months in order for a fix which is already written and merged to be shipped to them? If we only ship it to those customers then it's not fair to the rest of our users nor the rest of the community (this is why SUSE has a Factory-first policy where all SLE changes must land in openSUSE first). And finally (in rare cases) the upstream might not accept patches that are required in order for some distribution features to work because they fundamentally disagree with the feature. What are we supposed to do in those cases? Either way, someone will complain because the best solution (merge it upstream) is closed off. While it would be ideal if downstream patching was unnecessary, that's not the world we live in. Again, I do submit patches upstream religiously -- but it's not as cut-and-dry as you might think.

pg_bot 7y ago
Fork the project, prefix the command with your company name and tell them to use that command with the patch applied if they need it today. This solves all your problems.
- cyphar 7y ago
  I think you're over-estimating how many users are willing to change their workflow or scripts to accommodate things like this. They will switch away from your distribution to one which patches the actual package. I also don't agree this would result in fewer upstream bug reports -- "suse-foobar" will still result in bug reports for "foobar" (I've seen some cases of this happening). You'd need to rename the project entirely so that users don't know what the upstream GitHub repo is, and that's even more anti-community than any other suggestion.