Skip to content

CDM 2019 02

Jump to bottom
Chris Beach edited this page May 8, 2019 · 1 revision

openEQUELLA Community Dev Meeting February 2019

2019-01-31 (US) / 2019-02-01 (AU)

Attendees

Chris B, Aaron H, Cath F, Christian M, Ian S, Jolse M, Nick , Sam

Working Agenda

Specific Topics

  • Merge the equella/equella-autotests into the equella/Equella repo (I Stevenson)
  • oEQ Java Versions and the future (I Stevenson)
  • Code Climate (I Stevenson)
  • Git flow discussion (https://groups.google.com/a/apereo.org/d/msg/equella-dev/eByBtgZcHnk/GaWIKF4dEwAJ)
    • also... Should we maybe then protect our master and develop branches; or, should we change more to a forking setup
  • GitHub Org and Repo names - should they be changed to openEQUELLA? (I Stevenson)
  • equella.github.io landing page (I Stevenson)
  • Concerns with PRs which make changes across the whole repo (I Stevenson)
  • PRs

General Topics

  • Discuss code enhancements since last Dev mtg
  • Review tech choices, code structures, direction
  • Any tech debt concerns
  • Open PRs to discuss
  • Q&A

Minutes

  • Merge the equella/equella-autotests into the equella/Equella repo (I Stevenson)
    • Historically been separate repos, recommend we merge the two since the autotests have been revised and are working now.
    • No concerns - Ian S will make the merge. Branch into a subdirectory on both repos, and merge the tests into the main repo, and then hook in the CI.
  • oEQ Java Versions and the future (I Stevenson)
    • Coding and building should be consistent. Currently using Oracle JDK
    • CI builds use OpenJDK
    • Difficult to use OpenJDK with applets
    • OracleJDK 11 drops support for JNLP
    • IcedTea might help make OpenJDK work across the board
    • Besides the applets / jnlp issue, currently oE doesn't build in Java 11. Code, build, run on Java 11, but target Java 8.
    • Adopters are concerned about using old versions of Java
    • How to fix? Ideally remove the applets, web start
    • Proposed: Sunset File Manager and In-Place File Editor, and turn the JNLP Admin Console launcher into a Java launcher, and remove the JNLP build from the sbt - ideally in 2019.1
    • Folks need to review with their clients / adopters of oE, discuss internally, and see if there are any major concerns to address.
    • Mid-next week, IanS/Chris discuss outcomes and next steps.
  • Code Climate (I Stevenson)
    • Code climate is being a bit ignored atm, other github apps are available.
    • Would be useful to have the tool tie into SBT
    • Possible options for code style: CheckStyle, ScalaStyle, linters
    • Consider automatic code style formatting...
    • Ian can raise the github issues, and remove code climate as a starting point
    • As time allows, folks can grab the tickets as they have time.
  • Git flow discussion (https://groups.google.com/a/apereo.org/d/msg/equella-dev/eByBtgZcHnk/GaWIKF4dEwAJ)
    • also... Should we maybe then protect our master and develop branches; or, should we change more to a forking setup
    • develop has been setup, and configured as the github default branch for ease of opening PRs
    • git flow was suggested since there is experience on the team and its a standard newcomers can use
    • Proposal:
      • develop and master are the long-lived branches
      • master is the latest stable branch (release) of the app
      • 'releases' are tagged on the master branch
      • if a backport needs to occur on something earlier then the latest stable branch (ie master), then a release branch off of master would be created and persisted.
    • No concerns from the group.
    • Action item: Update the readme (Ian S)
  • GitHub Org and Repo names - should they be changed to openEQUELLA? (I Stevenson)
    • equella github project was created pre-open-source for moodle integration
    • concerns about infringing on the 'equella' trademark
    • concerns about linking
    • Action item: figure out the priority of changing the names (ChrisB)
    • Action item: figure out what project it should be under (openequella vs apereo vs ?) (ChrisB)
    • Action item: Make the changes, update links, get the word out. (Pending the previous two items)
  • equella.github.io landing page (I Stevenson)
    • The docs need some TLC, nicer landing page
    • Would be good to have consistent branding (Charlie, Sam, & possible another UX resource - maybe ask on the google forum) (Chris B)
    • The old 'starburst' icon had to be replaced
  • Concerns with PRs which make changes across the whole repo (I Stevenson)
    • makes diffs difficult to manage
    • For the specific PRs of code style, maybe just make the changes now, all at once, and then avoid repo-wide PRs if possible.
    • Consider the code style PR and license header PR and then try to avoid in the future
    • Folks are agreed on this path.
  • PRs
    • PR - build: configure renovate bot ( https://github.com/equella/Equella/pull/719 )
      • Monitors dependencies, and decides it's outdated, it'll open a PR. It is highly configurable, supports a wide range of package managers
      • Concern is how to merge in the PRs and make sure the project is still working
      • Concern with LoE for testing upgrading deps for the sake of upgrading deps.
      • Agreed that upgrading deps make sense for security, feature, or bug fixes
      • When upgrading deps, do it early in a release cycle
      • Agreed - for now, don't use renovate, but whoever opens a dep upgrade PR, run the autotests, smoke test it locally, and do so early in the release cycle.
      • Javascript testing - currently there are no Javascript testing inplace. Discuss at the next CDM (Christian M)
    • PRs - Storing IntelliJ Project Settings
      • Most of the current devs are using intelliJ
      • It would help newcomers using intelliJ
      • It's optional for developers to use
      • Still has some issues to work out (fix or remove)
      • Primary value-add is code style. Considering removing this PR, and focus on the code style
      • Code style:
        • Using the Google Java format and discuss in the forum, align in next CDM (Christian M)
        • There should be a SBT task to check format, and then add it as build checks
        • Should include Scala, Purescript, Typescript, Javascript style checkers
          • Scala, Purescript - (Jolse)
          • Typescript, Javascript, CSS, SASS - should be in the Google Formatter
      • PR 724 - concerns on performance to build out in-app
        • Consider using a third party tool
        • It would be an optional choice
        • Implementation will be component based
        • It will be different charting / analysis than BIRT, both for the old and new UI

Action Items

Action Item Person
Merge equella-autotests into Equella I Stevenson
Update README.md to tell people which branch to use under Git Flow I Stevenson
Discuss next steps for providing an Admin Console package C Beach & I Stevenson
Remove Code Climate from GitHub checks I Stevenson
Add GitHub Issues to look into incorporating CheckStyle and ScalaCheck I Stevenson
Check if there is a priority to change the GitHub organisation and repo name C Beach
Check what project/org Equella should be under C Beach
Prepare discussion on JS testing for next CDM C Murphy
Distribute to dev mailing list ideas for Java/JS Code Style to adopt (probably Google's) C Murphy
Distribute to dev mailing list ideas for Scala/Purescript Code Style to adopt J Maginnis

Navigation

Clone this wiki locally