Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Add notes


  1. Status of In-Review tickets


    serverDuraSpace JIRA



  1. Andrew Woods
  2. William Welling
  3. Rachid Belkouch
  4. Sacha Jerabek
  5. Don Elsborg
  6. Huda Khan
  7. Brian Lowe


  1. i18n sprint
  • Three unassigned bugs need to get looked at.
  • 1a. VIVO-1837: looks like there is a clear path forward
    • Raises issues of setters/getters where things are not always set and you don’t know when to expect null.
    • Brian will create an issue to review the newly-added RDFService.get/setVitroRequest() methods and ideally eliminate them.
    • Other longer-term issues to address similar problems with tight coupling / undesirable references to other objects elsewhere in the codebase:
      • Andrew wonders whether there is specific functionality (such as frontend decoupling) that will help surface and address some of these issues.
      • William thinks a new dependency injection approach is required first in order to avoid perpetuating bad patterns on both sides of the decoupling.
      • Huda has a good sense of where the cleavage points are for surfacing data to the API.
  • 1b. Need to examine files that have been touched by both the sprint branch and recent core development to make sure that core changes have not been lost/reverted.
  • 1c. Might be a matter of making sure that the initial RDF file loader recognizes the .nt (N-Triples) file extension and doesn’t try to parse as RDF/XML.
  • Sacha: need to figure out how to address backlog of documentation tasks.

Git process (William)

  • Propose two sprint branches: base branch (unchanging) plus staging branch.  Features are developed off of the base branch. Conflicts get resolved in staging.
    • Most important benefit is feature isolation. Conflicts should be resolved at the end of the feature instead of all throughout feature development.
    • Also avoids race to get into staging.
  • Current sprint-i18n branch is effectively staging, but we don’t all start developing new features from the same point.  Makes it hard to build pull requests and test them in isolation because there isn’t an agreed-upon base branch.
  • Something for next sprint, not to try to change now.
  • If conflict occurs when merging to staging, create new feature-merge branch to resolve the conflicts without polluting the feature branch.
  • Integrating of all features / conflict resolution occurs at end of sprint.
  • Major refactoring happens just prior to sprint so that the base branch includes the refactoring.
  • Cleanup happens at end as well.

Spring post-meeting 11 AM EDT Monday 24 Aug.

Draft notes in Google-Doc