2022-10-12 Meeting notes

Marc Johnson is next, followed by Ingolf Kuss 

Craig McNally / Jeremy Huff 

• Jeremy Huff will be running the meeting next week as I will be unavailable.  
• The chairs from the three councils have been discussing meeting once a month.  Doodle polling has been conducted and it seems we may have found a time that works for most/all.  It's still unclear when the first meeting will be held, but we will provide an update afterwards.  The goal is to improve communication/alignment amongst the councils.

All

• Reviewing assessment of mod-oa TCR-6
• Jeremy Huff raised a question about the ambiguity in expectations around what local installation document is needed
• Jeremy Huff described how there are integration tests, however they aren't written in Karate
• Marc Johnson  suggested that the ambiguous use of integration tests is the cause of the confusion on this criteria. And that the expectation of using Karate for integration tests refers specifically to the centralised API integration tests which are separate from the module, not integration tests within the module source (as those cannot use Karate, rather they must use the language of the module)
• It was agreed that this criteria would be reviewed in the new working group (initiated below)
• Jeremy Huff explained that the 80% coverage criteria failed, despite the agreement last week to exclude generated code, due to the submitters having not provided evidence of coverage being above 80% with that excluded
  Jeremy Huff advised that the sonar criteria could not be evaluated because the build was not integrated with Sonar
• The TC agreed to fail the evaluation of mod-oa. It will not be included in the Nolana release of FOLIO
• Owen Stephens thanks Jeremy Huff for his evaluation. He suggested that some of the criteria are challenging to achieve with their current technology stack and that this mismatch is deterring folks away from using a particular technology stack if folks seek inclusion in the flower releases. He asked if that is what was intended to be achieved?
• Craig McNally advised that this topic would be discussed by the new sub group
• Jeremy Huff asked Owen Stephens to articulate these concerns for the new sub-group to discuss

Nothing to review

Reminder to elicit feedback from three people on the top three things they think FOLIO can do better, and get them added to the document

There's a template at the top of the doc you can copy/paste into your own section, then add your informant's feedback.

All

Goals and Objectives

• Tod Olson described the challenge that he and Radhakrishnan Gopalakrishnan are having in translating the challenges folks are raising into an actionable set of goals and objectives
• Radhakrishnan Gopalakrishnan shared how he is converting the topics in the source documents into Tech Debt issues and asked if this is a sensible direction for the group?
• Radhakrishnan Gopalakrishnan expressed that there is separate need for managing the technical debt going forward
• Craig McNally asked how we wrap this up?
• Marc Johnson suggested that a reason we are finding this hard is that this is an external request from the CC and we didn't really know what that meant. Could it be worth sharing with the CC where we are and getting their advice?
• Craig McNally stated that he wasn't confident that would be helpful and that we need to get something down, close this subgroup down and start another sub-group for further refinement / progress
• Radhakrishnan Gopalakrishnan Asked what the something is we should get down?
• Craig McNally said that we need to get goals, objectives and initiatives written down and offer to provide further guidance offline

Controlling AWS Costs

• Mark Veksler advised that KubeCost has been deployed and is being tried out. The KitFox team are investigating how to track costs not covered by this tool e.g. RDS, MSK and OpenSearch.
  Peter Murray has asked started conversations about free / reduced cost licensing of KubeCost

Breaking Changes

• Jeremy Huff advised that we need to make a decision about how much we invest in the communication aspects of this sub-group. The group is working on an RFC for defining breaking vs. non-breaking changes.

Module Evaluation

• Craig McNally advised this is a new group for this
  Jeremy Huff suggested a modified version of the criteria is a output
  Craig McNally suggested including gathering of feedback and a retrospective
  Jeremy Huff suggested that there is a desire for this process to be more inclusive, maybe we need to analyse making the process more inclusive
• Zak Burke suggested we solicit advice from submitters, especially around expectations
• Craig McNally advised that the rest of the expectations can be worked on offline

Craig McNally

• Upgrade to Spring Boot v3.0 ?
  • There's a lengthy discussion in #folio-spring-base about this.  Here are some highlights:
    • Spring Boot 3.0 requires Java 17
      • Has implications for scratch envs – currently don't support Java 17
    • Spring Boot 2.7.* - OSS supported ends Nov 2023
    • Other related frameworks - OSS support ends May 2023.  See Nolana#Frameworks.1
    • FOLIO's Nolana support period ends around August 2023 assuming a similar cadence to previous FOLIO releases: FOLIO Support Policy
      This gap of at least three months (Jun, Jul, Aug) puts FOLIO implementers at risk because Spring versions that have reached their end of life are neither monitored for security issues nor get patches that fix vulnerabilities.
    • Spring Boot 3.0 isn't GA until Nov 2022...  from https://spring.io/blog/2022/05/24/preparing-for-spring-boot-3-0:

Although we don’t recommend it for production, you can try Spring Boot 3.0 milestones today to see how hard it will be to migrate your project.

Today:

• Craig McNally advised that the release coordinator organized a meeting with with some of us.  The outcome being that we all felt that we need more information about the level of effort required to upgrade to Java 17/ Spring Boot 3.0 before making a decision.  As such, the plan is to upgrade for Orchid (team spring-force).  Then, once we have a better idea for the amount of effort required, the councils, cap planning, etc. can discuss how to proceed.  Options could be:
  • • Adjust the support period for Nolana
    • Backport the Java 17/SB 3.0 upgrade to Nolana in a hot fix release.
• Marc Johnson expressed surprise, as an active participant in previous conversations, about this meeting

Radhakrishnan Gopalakrishnan 

Previous:

• Tools/dependency versions - Radhakrishnan Gopalakrishnan took on this topic as a project. There is also a proposal Managing Tools/Framework Dependencies currently in Draft stage with feedbacks as latest as 02.08.2022.

• Radhakrishnan Gopalakrishnan advised that he was meeting with Marc Johnson on Friday to resolve outstanding questions and that this work should be ready for next week

Craig McNally 

See below.  The list has grown over time with some of our meetings focusing of things like TCRs.  Let's review the list and prioritize.

• Marc Johnson advised that the technology changes and releases topic can be removed from the list and combined with the tools / dependencies versions work
• Craig McNally asked if any of these topics need to move to the top of the list?
• Marc Johnson and Ian Walls suggested that we should address the charter topic first, because it is foundational, or remove it from the list
• Craig McNally agreed to keep this at the top
• Craig McNally suggested that we remove this topic after this meeting.

Context

Conversation started in slack:

The Data Migration subgroup of SysOps has been struggling with how optimistic locking has interfered with batch update in Inventory. They've asked me to bring it to TC to see if there's a way to push this forward. The current open ticket is MODINVSTOR-924 Batch update with optimistic locking disabled. (This was split off from MODINVSTOR-910.)

Topic has been addressed. Core team has agreed to implement as separate API that disables optimistic locking.

See also Bulk Operations redesign, different issue but seems related.

Conversation

• Tod Olson advised that the optimistic concurrency controls topic is still relevant due to the unintended side effect of introducing those controls was to break some of the expected behaviour of the batch APIs in mod-inventory-storage. And that this relates to the project for bulk operations redesign
• Craig McNally asked if that is a topic for the TC or for the teams and TC members can participate if interested
• Marc Johnson advised that the the TC has missed the opportunity for involvement in this to a certain extent. The Core Platform team have already decided to provide a set of batch APIs that disable optimistic concurrency controls. This work has been planned and a pull request has been submitted for review
• Marc Johnson suggested that we need to be careful to consider that the bulk operations and batch APIs work are separate and being worked on by separate parts of the community
• Craig McNally  and Tod Olson agreed that the topic should be removed from the backlog
• Owen Stephens asked if the impact of the decision to provide APIs to by pass them is of interest to the TC given that the original optimistic concurrency controls was a topic discussed by the TC
• Marc Johnson suggested that to answer that question, the TC needs to decide on whether it wants to review important technical decisions after they are implemented or whether teams need to engage with them beforehand
• Craig McNally suggested that we don't have the bandwidth for these decisions to come through the TC, as demonstrated by long the topic was delayed, and we don't want to hold up the teams. There needs to be a judgement made based upon the impact of the topic. And that he is not familiar enough to do that in this case 

Previous:

Members were asked to review the TC charter in preparation for today's discussion.  

• Go through the charter together?
• Are there specific areas of the charter we should focus on?
• Is anything that's missing, or should be removed?

Notes: TC charter has been updated recently, how would the TC like to review it?

Jeremy Huff Was it written by TC or by someone else? - Craig McNally It was written by TC?

Craig McNally Let's create a draft version, discuss it, communicate to other councils before publishing

Tod Olson A comment to Guiding Principles .... (smth that should be explicitly stated as a GP) - Tod will add a comment to the doc

Some conversation followed.. some comments were added to the doc itself

Review and comments from TC members are welcome

After review, what will our rewrite process be?

Suggestion: make a subgroup to handle the rewrite.