4 ms·
That raises the question: what is the current etiquette around deciding whether to pester a dependency's author to include your fixes or just fork it, especiall
by mwcampbell 3y ago
That raises the question: what is the current etiquette around deciding whether to pester a dependency's author to include your fixes or just fork it, especially if it looks like you will be the biggest user of that dependency? I'm dealing with that question for a dependency that I want to introduce in one of my crates, but ideally not until at least one of my own fixes is merged.
- foverzar 3y agoObviously fork it, implement your feature, battle-test it, fix and make it more generic, battle-test it again, then ask the maintainer if they would be interested in a pull request. I mean, implementing your fixes in the first place means you are already inherently forking it.
- cocoa19 3y agoMy thought process is: 1. You find a bug, open an issue. 2. If bug is a minor issue, wait. If I want a fix really bad, offer to fix it. 3. If I still want a fix really bad and author did not respond, or does not want a fix, then fork the project for my own consumption. Using alternative dependencies are also an option.
- hughesjj 3y agoYup, and forks don't have to be permanent. Imo be ready to fork all the things if need be. Get comfortable with it before you're forced to.
- RussianCow 3y agoIn my opinion, you should always ask the author first. Having your changes accessible from the primary repository is much easier and better for everyone, and there is a good chance the author is happy to accept your PRs. On the other hand, they might not agree with your proposal or might want to make significant changes to the design, at which point it becomes a personal tradeoff for you.