• 0 Posts
  • 37 Comments
Joined 1 year ago
cake
Cake day: June 20th, 2023

help-circle









  • In my experience, I prefer to review or contribute commits which are logical changes that are compartmentalized enough that if needed, they could be reverted without impacting something completely differently. This doesn’t mean 1 commit is always the right number of commits in a PR.

    For example, if you have a feature addition which requires you to update the version of a dependency in the project, and this dependency update breaks existing code, I would have two commits, being:

    • Update dependency and fix issues because of the upgrade
    • Add new feature using new dependency

    When stepping through the commits in the PR or looking at a git blame, it’s clear which changes were needed because of the new dependency, and which were feature additions.

    Obviously this isn’t a one size fits all, but if someone submitted a PR with 12 commits of trial and error, and the overall changes are like +2 lines -3 lines, I’d ask them to clean that up before it gets merged.










  • Are you referring to hashicorp with recently changing license terms? IIRC the change in license was to prevent competitors (i.e. AWS) from releasing a service using the open source software from directly competing with their cloud offerings. It’s sad it had to come to it, but I think the reality of the situation is that AWS could come up with a competing cloud offering, has the built in user base, and can run the service at a loss, because they make money elsewhere.

    A company like Amazon totally could afford to pay, but won’t if they don’t have to. Ultimately, I think part of the license change was in response to Amazon and AWS being a monopoly. Without the license change, their company was at risk.