Child pages
  • Samvera Tech Call 2020-07-01

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Deprecation Message Style
    • Jeremy submitted a PR where a method was deprecated, active voice used, "we will be deprecating"
    • Question: Who is "we"?
    • Passive voice: "Will be deprecated" is used elsewhere, there is a lack of accountability
      • Active voice has more accountability, but perhaps shouldn't be "we"
      • Perhaps "Samvera will deprecate..."
      • Doesn't a deprecation message already give some indication as to where in the code base the message is originating?
        • Yes, usually the line is referenced
      • Some feel as if determining whether "we" is used might not that be that important, the deprecation warning itself is the essential factor
        • Also, ensuring that the line of code where the deprecation message originates should be in place
      • Conclusion: Usage of "We" is inconclusive
  • Renaming GitHub repository `master` branches
    • Connotations of slavery with the usage of `master`
    • Emory is switching to using `main`, Cornell supports this change
    • We should be mindful of links to URLs containing branch names in documentation or elsewhere
    • There should be a time period for when this is occurring
      • We can use this opportunity to then also explain to the community why this change is being introduced
    • Emory: Created a separate "main" branch without deleting "master", and fast-forward pushing commits to "main"
      • git merge --ff-only
      • In the process of issuing pull requests against "main"
      • Still in the process of switching to "main" as the default
      • Will retain "master" for a time period, just to ensure backwards compatibility
    • Samvera should frame the rationale, and then draft a series of action items for the migration plan
      • Jeremy volunteered to write the framing document
      • An implementation plan will follow this
    • Gemfile Support
      • Adopters of Gems and forks use `master` against GitHub projects can break when the `master` branch is specified 
        • Also, coordinating builds between repositories which explicitly reference to specific commits on `master` or referencing `master` generally can introduce issues
      • Renaming the git branch `master` is possible
        • But, it might be an easier transition to support two branches for the immediate future
      • Specify a date by which to permanently end support for `master`
        • Offer a README detailing why adopters should not use `master` any longer
      • Nurax Cases
        • There are customizations atop of GitHub `master` branches
        • This could break automated deployments
    • How to determine the new name of the default branch
      • When the initial message is sent to the community, no name should be given
        • `main` and `trunk` have been proposed
        • Perhaps a very short-lived WG could be formed in order to draft a document?
          • This has been successful once before
          • All attendees agreed that this would be good, Jeremy volunteered to investigate what would be necessary
            • The WG, then, would produce the document shared with the community
    • Rachel will investigate the impact that these updates will have on Nurax
  • samvera-tech Group Question
  • Pull Request Review
  • (Postponing the discussion for the CONTRIBUTION.md until the next call)
  • Next Call
    • Moderator: Jeremy Friesen
    • Notetakers: Tom Johnson
  • Meeting adjourned at 09:37 PDT/12:37 EDT