Versions Compared

Old Version 4

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version 5

changes.mady.by.user Tim Donohue

Saved on

Key

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

...

  • (30 mins) General Discussion Topics
    1. DSpace 7 at OR2022 - What talk(s) are we submitting for OR2022? Proposals due on March 6.
    2. Review tentative 7.3 Release Schedule above. This is based on a new 4-month release window, but could conflict with OR2022 plans.
    3. Any assigned 7.3 work needing early discussion?
      1. What do we need out of e2e (end to end) tests in the Angular UI?  Prompted by discussion of https://github.com/DSpace/dspace-angular/pull/1513
        1. Should e2e tests be only supported against a full DSpace REST API backend, with valid test data (like the Demo entities test data set)?
          1. Cypress notes some advantages/disadvantages: https://docs.cypress.io/guides/guides/network-requests#Use-Server-Responses
          2. Advantages: More like a full system test.  May allow us to automate some of the (usually manual) tests that currently only occur during Testathon.
          3. Disadvantages: May not perform well if you attempt to run it against api7.dspace.org (demo site), as these tests would be highly dependent on the backend being responsive (any major delays in responsiveness will result in tests timing out / failing).  May require local backend with valid test data.
        2. Should e2e tests be only supported against mock data (e.g. via Cypress Stubbing)?
          1. Cypress notes some advantages/disadvantages: https://docs.cypress.io/guides/guides/network-requests#Stub-Responses 
          2. Advantages: Much better performance of tests. More stability running tests both locally and in GitHub CI.
          3. Disadvantages: Mock data must be accurate at all times. If the mock data is ever "out of sync" with the backend responses, it's possible that e2e tests may not find bugs or errors that would exist in a real site.
        3. Recommendations from Cypress
          1. Use full backend for critical paths in your application, or places you want to drive the application like a user would
          2. Use stubs/mocks for edge cases or "hard to create" application states
          Should e2e tests be runnable against both mock data or a full backend?
          1. Advantages: Both of the advantages provided above.  Mock data could be used for quick verification, while a full backend provides more detailed testing.
          2. Disadvantages: Maintenance.  Also may require test duplication as it's unclear if Cypress can run the same tests against either mock data or a real backend.
      2. (Tentative, only if time allows) What to do about SWORDv2 support?  The Java SWORDv2 library will break as soon as we upgrade Solr Client to 8.10.0 or above (currently we are on 8.8.1), see https://github.com/DSpace/DSpace/issues/8188
        1. How can we address this rapidly?  (If there are any future security vulnerabilities from Apache Solr which require us to upgrade to the latest version of 8.x, then we'll immediately break SWORDv2.)
  • (30 mins) Planning for next week
    • Review the Backlog Board - Are there any tickets here stuck in the "Triage" column?  We'd like to keep this column as small as possible.
    • Review the 7.3 Project Board - Assign tickets to developers & assign PRs to reviewers.
      • Paid (by DSpace project) developers must keep in mind priority. If new "high" or "medium" priority tickets come in, developers should move effort off of "low" priority tasks.
      • Volunteer developers are allowed to work on tickets regardless of priority, but ideally will review code in priority order.

...