4 ms·

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

by 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.
- wolfgke 7y ago
  > and that's even more anti-community than any other suggestion. Shipping a fork that is different from the version that is created by the original author is also very anti-community. At least make it clear that you ship something different from the program that the author maintains.
  - cyphar 7y ago
    The key phrase was "even more". I disagree that all patches are somehow ethically wrong (bugfixes and security patches are obvious counterexamples). Not to mention that if the author felt otherwise, they wouldn't have released the code under a license that allowed you to modify and redistribute your modifications. But making massive changes to a project that are incompatible with upstream is definitely not a good thing to do without reason.
    - wolfgke 7y ago
      > I disagree that all patches are somehow ethically wrong (bugfixes and security patches are obvious counterexamples). Not to mention that if the author felt otherwise, they wouldn't have released the code under a license that allowed you to modify and redistribute your modifications. The fact that the author does not forbid it does not mean that he/she wants changes or even encourages them. It just means that the author believes that the downsides of completely disallowing changes are even worse.
      - cyphar 7y ago
        There are free software licenses that require you to rename the project if you modify it. But I digress. This whole discussion is about trade-offs -- if you cannot get the patch upstream but you need to ship it what is the next best thing. I would contend that patching it is better than patching and renaming because renaming doesn't help solve the problem (unless you are very radical and rename the project entirely) and makes things less convenient for users. And note that distribution users are part of the community of people using the software.
        zapita 7y ago
        The solution is to either 1) patch it and rename your fork completely, or 2) ship upstream unmodified and use the same contribution process as everyone else to get patches in. That is how everyone else does it. Only distributions are somehow exempt from fork etiquette. Hold yourself to the same standards as everyone else, and the problem goes away.
        cyphar 7y ago
        I disagree that everyone else does this except distributions. Companies apply their own patches to projects all the time (as an upstream maintainer I've been asked several times to help debug a patch that some company has used internally). Almost every company using Linux has patches on top of it that are for their specific project (all versions of Android have a forked Linux kernel). GitHub uses patched versions of Git (though one of their engineers is also incredibly prolific upstream). And so on. The reason why people think distributions are the only ones doing it is because we maintain all of the software that is available for a full Linux system. So instead of only having patches for just one or two projects, we have patches for (probably) ~50% of packages in our distribution (most are bugfixes but there are plenty of not-just-bugfix examples). I think some folks just like to bash distributions because no matter what decisions we make we're going to piss someone off. But again, we don't apply downstream patches because we like it. In fact downstream patches are an outright headache because we have to rebase them on version upgrades and so on.
- pg_bot 7y ago
  This is meant to be temporary. If it is truly crucial they will update happily. If it's not they can wait. Submit the patch upstream, if it is accepted you can then deprecate your code and create an alias, if it's not congratulations you get to maintain a fork. This changes the culture from you clobbering the original package maintainer, to one where you can adapt when necessary but are still a good community member. The "foobar" people can point people to use "suse-foobar" as a solution until everything has been resolved. It's not the number of bug reports that matter, it's that you can easily and quickly come to a speedy resolution as an end user.
  - papln 7y ago
    This is also how non-standard and standards-track CSS features work . The vendors promotes CSS keys like -webkit-marquee-rainbow-animation-spectrum while waiting until all the browser vendors agree on the final spec for marquee-rainbow-animation-spectrum. For unix tools, downstream vendors could choose to rename the binary (redhat-procps) or rename the flags (procps -- rh-c) if it wasn't incredibly ugrent to choose a single-letter flag name. https://developer.mozilla.org/en-US/docs/Glossary/Vendor_Prefix https://developer.mozilla.org/en-US/docs/Glossary/Vendor_Pre...
    - cyphar 7y ago
      How happy would you be to use a system where 50-75% of commands start with "debian-" or "ubuntu-" or "redhat-" or "suse-" (assuming that all patches have to obey this renaming rule)? As a user, I personally wouldn't want to use a system like that and I would switch distributions to one where I don't have to repetitively type out the name of my distribution into a shell.
      - pg_bot 7y ago
        I think you've completely missed the point. It should be very rare to need to ship a fork of a project to end users. Patches should first be targeted at the upstream project, but in the rare case where it needs to be used today you should follow this path instead of messing up the API. By doing this you can explicitly set expectations that the changes you are making are temporary and will be deprecated immediately once you get back in sync with master. As an end user this is ideal, I can get a fix shipped today with the tradeoff that I will have to do a bit of maintenance in the future. Any other way leads to long waits, or chaos.

by 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.

wolfgke 7y ago
> and that's even more anti-community than any other suggestion. Shipping a fork that is different from the version that is created by the original author is also very anti-community. At least make it clear that you ship something different from the program that the author maintains.
- cyphar 7y ago
  The key phrase was "even more". I disagree that all patches are somehow ethically wrong (bugfixes and security patches are obvious counterexamples). Not to mention that if the author felt otherwise, they wouldn't have released the code under a license that allowed you to modify and redistribute your modifications. But making massive changes to a project that are incompatible with upstream is definitely not a good thing to do without reason.
  - wolfgke 7y ago
    > I disagree that all patches are somehow ethically wrong (bugfixes and security patches are obvious counterexamples). Not to mention that if the author felt otherwise, they wouldn't have released the code under a license that allowed you to modify and redistribute your modifications. The fact that the author does not forbid it does not mean that he/she wants changes or even encourages them. It just means that the author believes that the downsides of completely disallowing changes are even worse.
    - cyphar 7y ago
      There are free software licenses that require you to rename the project if you modify it. But I digress. This whole discussion is about trade-offs -- if you cannot get the patch upstream but you need to ship it what is the next best thing. I would contend that patching it is better than patching and renaming because renaming doesn't help solve the problem (unless you are very radical and rename the project entirely) and makes things less convenient for users. And note that distribution users are part of the community of people using the software.
      - zapita 7y ago
        The solution is to either 1) patch it and rename your fork completely, or 2) ship upstream unmodified and use the same contribution process as everyone else to get patches in. That is how everyone else does it. Only distributions are somehow exempt from fork etiquette. Hold yourself to the same standards as everyone else, and the problem goes away.
        cyphar 7y ago
        I disagree that everyone else does this except distributions. Companies apply their own patches to projects all the time (as an upstream maintainer I've been asked several times to help debug a patch that some company has used internally). Almost every company using Linux has patches on top of it that are for their specific project (all versions of Android have a forked Linux kernel). GitHub uses patched versions of Git (though one of their engineers is also incredibly prolific upstream). And so on. The reason why people think distributions are the only ones doing it is because we maintain all of the software that is available for a full Linux system. So instead of only having patches for just one or two projects, we have patches for (probably) ~50% of packages in our distribution (most are bugfixes but there are plenty of not-just-bugfix examples). I think some folks just like to bash distributions because no matter what decisions we make we're going to piss someone off. But again, we don't apply downstream patches because we like it. In fact downstream patches are an outright headache because we have to rebase them on version upgrades and so on.
pg_bot 7y ago
This is meant to be temporary. If it is truly crucial they will update happily. If it's not they can wait. Submit the patch upstream, if it is accepted you can then deprecate your code and create an alias, if it's not congratulations you get to maintain a fork. This changes the culture from you clobbering the original package maintainer, to one where you can adapt when necessary but are still a good community member. The "foobar" people can point people to use "suse-foobar" as a solution until everything has been resolved. It's not the number of bug reports that matter, it's that you can easily and quickly come to a speedy resolution as an end user.
- papln 7y ago
  This is also how non-standard and standards-track CSS features work . The vendors promotes CSS keys like -webkit-marquee-rainbow-animation-spectrum while waiting until all the browser vendors agree on the final spec for marquee-rainbow-animation-spectrum. For unix tools, downstream vendors could choose to rename the binary (redhat-procps) or rename the flags (procps -- rh-c) if it wasn't incredibly ugrent to choose a single-letter flag name. https://developer.mozilla.org/en-US/docs/Glossary/Vendor_Prefix https://developer.mozilla.org/en-US/docs/Glossary/Vendor_Pre...
  - cyphar 7y ago
    How happy would you be to use a system where 50-75% of commands start with "debian-" or "ubuntu-" or "redhat-" or "suse-" (assuming that all patches have to obey this renaming rule)? As a user, I personally wouldn't want to use a system like that and I would switch distributions to one where I don't have to repetitively type out the name of my distribution into a shell.
    - pg_bot 7y ago
      I think you've completely missed the point. It should be very rare to need to ship a fork of a project to end users. Patches should first be targeted at the upstream project, but in the rare case where it needs to be used today you should follow this path instead of messing up the API. By doing this you can explicitly set expectations that the changes you are making are temporary and will be deprecated immediately once you get back in sync with master. As an end user this is ideal, I can get a fix shipped today with the tradeoff that I will have to do a bit of maintenance in the future. Any other way leads to long waits, or chaos.