Skip to content

CDM 2019 07

Jump to bottom
SammyIsConfused edited this page Jul 12, 2019 · 9 revisions

openEQUELLA Community Dev Meeting July 2019

2019-07-11 (US) / 2019-07-12 (AU)

Attendees

Cath Fitzgerald, Samantha Fisher, Amalia Flórez, Chris Beach, Christian Murphy, Nick Charles, Joe Shevland, Ian Stevenson, Penghai Zhang, Aaron Holland, Jolse Maginnis.

  • Chair (TBC): Nick C
  • Scribe (TBC): Sam F

Working Agenda

Specific Topics

  • Bb LTI/REST changes backported to 2019.1 post-release (CB)
  • File Manager and In-place editor planned deprecation and client requirements/solutions (CF)
  • Review code repo locations in the Apereo org, and consider moving to an 'openEQUELLA' org with reference to Apereo (CB)
  • Changing to forking workflow (IS)
  • Review action items around releasing 2019.1 (CB)
  • Streamline Release notes - align commit messages ( https://github.com/conventional-changelog/commitlint ? ), and then release notes a bulleted list, with the Features Guide digging into a deeper explanation on some of the enhancements (CB)
  • Cross Browser testing CI (CB)
  • Performance testing CI (CB)

Please add more.

General Topics

Minutes

Action Items Review

  • Create ticket for JestJS on unit tests (CB)
  • Follow up with Apereo legal about TinyMCE licence (CB)
    • This one is still up in the air, email to Apereo is planned to be sent by CB.
    • Looks like we'll need to remove the old embedded version of TinyMCE and replace it with the nodeJS one used in the login notice editor.
    • This would likely require significant work, since the old one was heavily modified, Aaron being one of the main developers who worked upon these modifications. (Custom plugin functionality, and also a button to start a selection session)
    • However, Aaron points out that he doubts anyone uses the custom functionality, so potentially this could just be dropped assuming clients are happy with that.
  • Send out a note for community to agree / align on abbreviation (CB)
    • This has been followed up on recently, CB expects to hear back in a few days.
  • Ian to review PR generalize headers (IS)
    • Ian confirms this has been fully addressed.
  • Investigate integrating Trello into wiki (CM)
    • CM has been doing some work on this. He has played around with GitHub Projects, and has confirmed that it is possible to create tasks without linked issues.
    • Now we have an action items board on GitHub - has a Kanban board with three lanes - To do, In Progress, Done.
    • One major benefit is that users don't have to log in to view action items, which aligns more with an open source community.

Specific Topics

  • Bb LTI/REST changes backported to 2019.1 post-release (CB)

    • Clients are somewhat hesitant about waiting to update all the way to 2019.2. As a result, there was A discussion between CB, Dan and Al. It was decided that as the fixes go in, they should be backported.

  • File Manager and In-place editor planned deprecation and client requirements/solutions (CF)

    • Cath has done investigation into the ramifications of this:
      • Some clients in the UK use the EBI to import large amounts of data, and require the file manager to access and edit the files.
      • Some AUS clients have used it extensively to manage folders.
      • When we looked into a solution, Carl suggested a temp xpath that should give access to those files, but after doing some digging it was determined that it wasn't that simple.
    • US adopters use it to upload their files, which are not necessarily stored as attachments. So if the file manager goes away, they can't access data and therefore it's a blocker to upgrading.
    • Urgency of deprecation - push to not require Oracle licensed Java. CF has had varying success with using IcedTea Web with the file manager, so that might not be the ideal solution.
    • Up to this point, clients have been able to use this feature for free and wouldn't be able to any more.
    • A note should be sent out to clients to warn them that they need to be working within the bounds of licensing.
    • Charlie proposed a solution involving an API that could be called to migrate out file manager attachments into standard oEQ attachments. However, it's a significant dev effort, in the file manager you can mark things as not appearing in the file summary. Even if there was a migration path we'd need to change the oEQ side of the code to account for that check, among other issues.
    • Cath points out that we've got one client that uses the in-place editor and file manager, and while they find it useful removing it isn't a blocker for them.
    • Aaron thinks that making a file manager that doesn't use Java applets wouldn't be too much work and would be a value-add.
    • There was an RDA feature request for a replacement file manager put up by Edalex, and it didn't get voted for.

  • Review code repo locations in the Apereo org, and consider moving to an 'openEQUELLA' org with reference to Apereo (CB)

    • CB has been talking with Ian about the access level we have, and it has been determined we aren't content with it. No one in Edalex or Unicon is an administrator so we have no control over access to the repos. If CB needed to manage groups, he'd require an Apereo admin. If he was made an Apereo admin, he'd have control over ANY Apereo repo which doesn't make sense since his work only involves oEQ and uPortal.
    • CB's original intention in moving the repos was to be more in compliance with open source agreements and move towards only using the phrase "openEQUELLA".There is no longer anywhere that reads "Equella" in the repos.
    • If we were to move to our own repos, Apereo admins still need access to them but we'd have full admin control.
    • Ian is all for the move back to our own repositories, as it stands the situation is unworkable.
    • In order to add people to groups we currently need to jump through hoops with Apereo. We cannot create our own repositories, and have limited controls over the repository configuration.
    • The only potential issue CB sees is that people want to know where the documention site was when it changed. He has agreed to follow up on that.
    • Ian is happy to fix any resulting issues with the CI upon the move.

  • Changing to forking workflow (IS)

    • This is not to be considered til after repo move.
    • Rather than all of us working on the one repo, better to all have our own forks and make PRs from there.
    • Jolse thinks its a good idea - he's already been merging in PRs from his own forked repository.
    • CB agrees - the uPortal project recommends doing that even if you are a primary committer to the main codebase.

  • Review action items around releasing 2019.1 (CB)

    • CB wants to know if there's any way the community can help with the release.
    • CB asks if there is a runnable script for creating a release. There isn't, but it has been considered by Edalex.
    • Administration of the version server is a manual process.
    • Another manual process is making the features guide - collaboration between CF and CB has been happening on that.
    • Testing - autotests are done as part of the builds. Manual testing is done by EDX on database differences.
    • Sending out notes to the community groups is another manual process.
    • Internally, Edalex has a release checklist. It would potentially make sense to have a community-facing one.
    • There was a discussion about where this checklist would go - core of OEQ, or the docs, or something else. We need alignment on this, CB likes the idea of keeping this in the core repository, as this as an end user guide.

  • Streamline Release notes - align commit messages ( https://github.com/conventional-changelog/commitlint ? ), and then release notes as a bulleted list, with the Features Guide digging into a deeper explanation on some of the enhancements (CB)

    • CB wonders if it makes sense to put release notes into the GitHub releases page - potentially automated based upon commit messages.
    • Changelog is currently in the Version Server - based upon trawling the commit log in the repo and (assuming the commit message is in the right format) it gets listed in the changelog.
    • In our CONTRIBUTING.MD it says to write quality commit messages and links to an example article.
    • CBs idea aligns with what is already done with the value-add that some of the infrastructure could be done by the community rather than Edalex.
    • As it stands, the version server is called by oEQ instances by the health check function, to check the version.
      • Potentially, we could migrate that to call the GitHub releases page API.
    • We'd have to manually generate the release notes, or write a script to do that.
    • The original idea for the version server was that you could release revisions to the releases without having multiple different revisions of each version.
      • IS points out that this is done exactly the same way in many other organizations - and can be scripted.
    • CB points out that it should be as automated as possible to reduce work and to list all changes for an accurate changelog.
    • This way aligns more with open source.

  • Cross-browser and performance testing CI (CB)

    • Cross-browser testing is an effort CB is looking at in uPortal after a browser issue was not picked up before release. First thoughts are cross-browser Selenium for browser testing.
    • There might also be benefit with cross-database platform testing - currently this is done manually by Edalex.
    • A problem IS raises is that lots of CI can be a prohibitive cost issue - CI is not necessarily free and the more we do, the more expensive it gets.
    • CB is only looking into free-for-open-source CI.
      • Currently only in the product identification process - finding the right servers to do this.
    • CB is considering performance testing, and looking into Jmeter scripts.

Discuss code enhancements since last CDM

  • We are currently in code freeze for the release candidate.
  • Work has started on 2019.2.
  • RenovateBot is currently in use for dependency update pull requests.
  • Towards the end of the release candidate, Jolse tidied up the Wizard area of the code, has now somewhat stabilized.
  • Jolse is currently working on a "create institution from scratch" feature.
    • He wants it in a wizard style where you can customize aspects of your institution before creating it.
  • Jolse did a lot of work on allowing the autotests to work on the new UI
    • We hadn't had any TestNG testing on the new UI up til now. There is an issues list on GitHub.
    • Currently there is a branch with these fixes.
    • 40 or so failures still - mainly because of scr(een)options.
    • Edalex is planning to work at fixing those - a few of which are going into the release.
    • Work was done in 2019.1 that allows you to configure the analyzer in the freetext index for different languages. Allowing for stemming and other Lucene features in other languages.
    • Attachment duplicate checking is being worked on and coming in soon- currently duplicate checking is possible just for text fields.
  • CB is focused on Bb/LTI integrations

NOTE:

Action Items are now listed on the GitHub Projects KanBan board.

Navigation

Clone this wiki locally