5 ms·

I had similar thought and I think that doesn't work well in practice: 1. If I have to get back to this project several months in the future, it might be a lot

by whs 2y ago

I had similar thought and I think that doesn't work well in practice: 1. If I have to get back to this project several months in the future, it might be a lot of trouble to bring the fork up-to-date. The fork might not have new features, security updates, compatibility upgrades that I want. The upstream may have rewritten the code, making my fork redundant or refactored it and I have to rework it again 2. I think it is in bad taste to submit PR without intention of getting it merged - it create open ticket that maintainers could perhaps never close and have to sort through.

chipdart 2y ago
> 1. If I have to get back to this project several months in the future, it might be a lot of trouble to bring the fork up-to-date. What's the trouble? What compells you to "bring the fork up-to-date"? > The fork might not have new features, security updates, compatibility upgrades that I want. I really don't understand what point you think you're making. The scenario you're discussing is either a) contribute a patch to an existing project, or b) write your own from scratch. Does scenario b) magically introduces feature and maintenance work on your alternative implementation? > 2. I think it is in bad taste to submit PR without intention of getting it merged (...) Why are you even considering this a scenario?