-
Notifications
You must be signed in to change notification settings - Fork 44
CDM 2019 08
SammyIsConfused edited this page Aug 2, 2019
·
8 revisions
2019-08-01 (US) / 2019-08-02 (AU)
- Chair: Chris B
- Scribe: Sam F
List of attendees: CathF, NickC, ChristianM, IanS, JoeS, JolseM, Penghai, ChrisB
- Review Action Items
- Specific Topics (Please add to below list, or email the equella dev list to have an item added)
- Discuss code enhancements since last CDM
- Review tech choices, code structures, direction
- Any tech debt concerns
- Open PRs to discuss
- Q&A
- 2019.1 Release (IS)
- Utilising hotfixes for 2019.1 going forward - aligning with Git Flow (IS)
- So going forward having releases like 2019.1.1, 2019.1.2, etc.
- Pinning down a stable version of Simple DB (IS)
- How to add simple 'Note' entry to GitHub projects (IS)
- New UI roadmap (CB)
- Alignment on https://github.com/apereo/openEQUELLA/issues/1137 (CB)
- Please add more
- Has been followed up on by CB with Apereo.
- We are not allowed to use TinyMCE bundled in, we'd have to have a method to pull it down as well as take out the bundled version.
- Potentially worth doing some sort of fall-back simple editor, or fall back to the TinyMCE CDN demo version, so that it TinyMCE is not pulled down the features will still be at least usable.
- Idea to switch between CDM demo version and in-equella version dependent on availablity.
ACTION ITEM: Create ticket for removing old TinyMCE.
ACTION ITEM: Create ticket for allowing for CDN/non-CDN TinyMCE switch.
- Apereo and oEQ Advisory Board approves this change.
- CB has a contact that will help us to do this.
ACTION ITEM: Migrate away from Apereo Organization on Github to retain full control over repos.
- Completed by Nick Charles. Issue closed.
- Little bit of initial research has been done, definitely looks possible to achieve this via GitHub APIs.
- We could look at scripting up a release publish script that will hook into the APIs to publish a build more simply than the current process.
- Action Item reassigned to Ian Stevenson. Ian will document the necessary steps to achieve this.
- We have an internal checklist, maybe we could have a higher level revision of this for the community.
- Action Item reassigned to Cath Fitzgerald.
- This issue is dependent on the repository migration, and will be revisited after that is completed.
- CB has not been able to find out much info on this one, has followed up with a client but they've been relatively silent about it.
- CF notes that an Edalex discussion happened regarding this and it has been determined that the deprecation of FM / IPFE is a low priority at the moment, likely to be a more gradual process.
- As it stands, oEQ 2019.1 will build with openJDK.
- Released this week.
- As a result, we are in an idiomatic Git Flow workflow structure.
- The release is merged from a release branch into master, then master into develop.
- one thing that came up conflicting during the merge was the implementation of support for non-English indexing.
- Merging a required classgraph dependency clashed with an old bouncycastle dependency, preventing build.
- After some digging it was determined bouncycastle was not directly required and so was removed to fix the clash.
- Typically in idomatic Git Flow you would have hotfix branches based upon master.
- Once reviewed and tested it is merged in to master and develop.
- Currently the oEQ solution does not quite match this, we have long running release branches.
- This was the fastest method of implementing fixes for various versions when Jolse was working alone.
- Since the Edalex dev team has grown and requirements for version specific fixes have dropped, there is little stopping us from moving to using idomatic Git Flow.
- Note; it's important that the version number fits oEQ's format, as the code assumes a specific format.
ACTION ITEM: IS and CB will look into whether or not this will work with oEQ.
- Simple DB library that Jolse wrote before oEQ.
- Stripped down, basic library that is used in a couple of places in oEQ (audit log, cloud provider table, some of the new db migrations)
- Tthe version that is in oEQ is old, Jolse is currently working on a stable, documented version.
- Currently waiting upon a release of a dependency of Simple DB that is in release candidate stage as a blocker for the release of a new Simple DB.
- Jolse says that before 2019.2 oEQ is released there will be a stable, documented version of simple DB.
- A concern raised is that the SNAPSHOT version suffix means that the dependency is pulled down each time the build happens - making builds non-deterministic.
ACTION ITEM: Publish non-SNAPSHOT version of current implementation of Simple DB so that we can use that one and make the build process more predictable.
- Potential risk of tech debt considering that Jolse is the sole maintainer of Simple DB.
- One of the main concerns is using two different libraries for the same purpose - simple DB and Hibernate.
- Jolse proposes that the time to move away from simple DB would be when upgrading Hibernate to a more recent version - but also that this could potentially be a sizeable task.
- A couple of Unicon clients are looking into 2019.1 and the new UI.
- IS notes that it is not yet feature complete, but that we are moving towards that.
- Work is being done to get the CI running autotests in the new UI.
- Once that is in, trusting the new UI's stability will be more viable.
ACTION ITEM: look into testing via Travis, such that both legacy and new UI can be tested upon build.
- New UI roadmap is a bit fluid at the moment - was initially expected that 2019.2 will include the new Search/Selection Session UI but the scope has been determined to be too large for that release.
- Edalex are looking into 2020.1 for that release and instead focusing more upon RDA items for 2019.2.
- Work could be done in parallel on that one with the work for 2019.2 to give more time and resources to the new search UI.
- CB suggests the possibility of the Unicon side of the dev community putting time and resources into this.
ACTION ITEM: CB will look into the possibility of the Unicon side of the dev community getting involved of this.
Alignment on ensuring oEQ is handling files appropriately - Unicon is setting aside some time to look into this, initial thoughts are improving the verbosity of the logging of item interactions. A rubbish-bin area that instead of a file being deleted, it is moved there and logged, and a system admin has to manually empty it.Consider the existing "Trash" folder, maybe making it more persistent.