4 ms·

Not speaking for Leland, and this is not a universal principle, but if you know what you're doing, you can write a solution and have it out of your way faster t

by duggan 2y ago

Not speaking for Leland, and this is not a universal principle, but if you know what you're doing, you can write a solution and have it out of your way faster than going through the bureaucracy of trying to get some code merged upstream.

chipdart 2y ago
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?
jrpelkonen 2y ago
On the other hand, maintaining a custom tool vs a patched fork is not that dissimilar, is it? If patching the prevalent tool makes sense otherwise, I wouldn’t worry too much about upstreaming.
- duggan 2y ago
  That's a fair point, particularly in the case of go. Be interested to understand the reasoning myself.
  - dhruvrajvanshi 2y ago
    Trying to understand a big existing codebase might be more difficult than rewriting a small subset for your own use case, especially for something as trivial as a parser for a relatively simple language like protobuf.
    - chipdart 2y ago
      > Trying to understand a big existing codebase might be more difficult than rewriting a small subset for your own use case (...) Adding a small feature to an existing codebase will never require more work than implementing a minimal working example from scratch.
      - marssaxman 2y ago
        Gaining enough understanding of that existing codebase to know how one would go about adding that small feature, on the other hand, can easily require more time than it would take to build what you need from scratch.
- chipdart 2y ago
  > On the other hand, maintaining a custom tool vs a patched fork is not that dissimilar, is it? You're somehow ignoring all the development work you need to invest to go from zero to alternative implementation, not to mention the maintenance work you need to do to come close in stability. The whole point of FLOSS is that everyone, including you, can build upon all the work invested by everyone else. Otherwise there would be a whole lot of people reinventing the wheel.

by duggan 2y ago

chipdart 2y ago

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?

jrpelkonen 2y ago

On the other hand, maintaining a custom tool vs a patched fork is not that dissimilar, is it? If patching the prevalent tool makes sense otherwise, I wouldn’t worry too much about upstreaming.

duggan 2y ago
That's a fair point, particularly in the case of go. Be interested to understand the reasoning myself.
- dhruvrajvanshi 2y ago
  Trying to understand a big existing codebase might be more difficult than rewriting a small subset for your own use case, especially for something as trivial as a parser for a relatively simple language like protobuf.
  - chipdart 2y ago
    > Trying to understand a big existing codebase might be more difficult than rewriting a small subset for your own use case (...) Adding a small feature to an existing codebase will never require more work than implementing a minimal working example from scratch.
    - marssaxman 2y ago
      Gaining enough understanding of that existing codebase to know how one would go about adding that small feature, on the other hand, can easily require more time than it would take to build what you need from scratch.
chipdart 2y ago
> On the other hand, maintaining a custom tool vs a patched fork is not that dissimilar, is it? You're somehow ignoring all the development work you need to invest to go from zero to alternative implementation, not to mention the maintenance work you need to do to come close in stability. The whole point of FLOSS is that everyone, including you, can build upon all the work invested by everyone else. Otherwise there would be a whole lot of people reinventing the wheel.