2 ms·

Your comment makes no sense at all. You do not need to get a PR merged before you can use your changes. You work out a patch, use it locally to meet your needs,

Your comment makes no sense at all. You do not need to get a PR merged before you can use your changes. You work out a patch, use it locally to meet your needs, post a PR, and you move on with your life regardless of whether your PR is merged or not. In fact, that's the whole premise of GitHub: you fork a repo, you work on a feature branch, you post a PR, anf your fork stays there. To repeat my point: it's easier to add small features to a parser than it is to reimplement everything, and posting a PR with your small change takes no work at all.

duggan 2y ago
> Your comment makes no sense at all. You do not need to get a PR merged before you can use your changes. What you said was: > Wouldn't it have been far more efficient to contribute back to protoc? My point was about the bureaucracy of contributing back upstream. Nonetheless, your new point, that patching and using your own fork is preferable makes sense on the surface given the ease of forking in go projects. Be interested to hear the author's reasoning.
- chipdart 2y ago
  > My point was about the bureaucracy of contributing back upstream. There is no bureaucracy. Once you have your patch, you can post a PR. Click on a button, write a description, and you're done. That's it. Posting a PR is hardly the hard part of the process.
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?

duggan 2y ago

> Your comment makes no sense at all. You do not need to get a PR merged before you can use your changes. What you said was: > Wouldn't it have been far more efficient to contribute back to protoc? My point was about the bureaucracy of contributing back upstream. Nonetheless, your new point, that patching and using your own fork is preferable makes sense on the surface given the ease of forking in go projects. Be interested to hear the author's reasoning.

chipdart 2y ago
> My point was about the bureaucracy of contributing back upstream. There is no bureaucracy. Once you have your patch, you can post a PR. Click on a button, write a description, and you're done. That's it. Posting a PR is hardly the hard part of the process.

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?