2022-10-05 Meeting notes

New Discussion

Jeremy Huff tcr-6 mod-oa has about 60% coverage over code, though much of the report includes generated code. It was decided that the calculations should be done manually to show > 80% coverage.

Craig McNally What is our official stance for plugins and shared libraries in regards to module acceptance? 

Zak Burke An informal analysis seems to indicate that the modules in question would likely pass an evaluation

Jeremy Huff Since the plugin code in question is being used in module code that has already been accepted then this usage should be grandfathered in. Tod Olson agrees.

Marc Johnson The teams could have asked about the guidance and perceived lack of governance. We should be careful about the cultural precedent that this sets.

Craig McNally There are subtleties and precedent that indicate this is how we should respond

Marc Johnson If there is precedent then we should stick with that precedent now

Jeremy Huff We should begin a new sub group to address several concerns with the evaluation process 

It was decided that the modules in question (see MODQM-293 - Getting issue details... STATUS ) will be allowed through.

Technical Council Sub Groups Updates

• Update from Vijay?
• 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.

Notes:

Tech Council Charter

What's the value of continuing the review in TC as a whole? Would provide a general summary of feeling about the current charge. Useful onboarding, or better to onboard with a revised charge?

Seems like a subgroup has formed: those who have actually commented

Decision: will continue with review, try to be quick and then hand to a subgroup

Review

Guiding Principles:

Need some revision per above, make these clear as they are what we go to when we are uncertain.

Motivation review:

Much language needs to change: relationship with PC is different, TC does not do resourcing, "platform" is a dubious term now.

Structure and Composition:

Much of this is redundant with FOLIO Governance Model. Should refer to that document, and retain only those items that supplement that document.

Responsibilities:

What does "own architecture" mean? When we reviewed a year ago, concluded we were not doing this well. There are some abandoned blueprint documents.

Do we think we are still responsible for this? Yes. The purpose of TC is to set some constraints or shared agreements about how the platform develops. TC does not have many options for enforcement, want compliance. Might affect how we approach the architectural guidance.

Opposing view: approach as agreement and consent rather than enforcement and compliance.

Giving teeth or power to the councils balances the weight of more powerful community members, like a check and balance. One challenge for the councils is that some voices have made decisions and councils have to retroactively accept these decisions. This creates a disincentive to talk to the councils as they may disagree. So incentive is to do first and ask permission later.

Define processes, etc.: need to be clear about project requirements v dev team domain

Maintenance of Contributor licenses, etc., CoC, etc.: Many of these seem to be for CC

Out of Scope: need to update the audience for these bullet points, broader than PC.

Key deliverables:

Much language inconsistent and out of date, some things up in discussion and may change radically.

May need two phases: short term immediate changes, then long term after other discussions resolve.

Architectural blueprint - have provided but need to update the deliverable.

RFCs: need to add ADRs

20 min

An overview was provided of the "hot topics" at WOLFcon.  It seems clear that the TC ought to be involved in these discussions/efforts;  what is the best way to participate?

• Platform minimal
• Applications/bounded contexts & application management
• Blue/green deployments
• Kafka/messaging improvements
• FOLIO governance
• API technical debt
• ???

Notes:

• Discuss if we want to try and do this during a TC meeting or schedule a dedicated meeting.
• What's working well for us?  What needs to be clarified?  
• Scope / level of detail,
• Clarify what information belongs in which section
• Is it mandatory for accompanying materials (details designs/proposals/etc.) to be on the wiki, or can they live in google docs, etc.?
• We agreed to do this sort of exercise after each RFC, but think it's worth doing this for ADRs - maybe not after each one, but periodically.
• Retro board: https://easyretro.io/publicboard/bk8DxfBbCeZIYL1pnsBPUN2xgYb2/a07d2c6b-754b-4446-8743-7f32f2911928

Introduce the topic

• What do we want to get out of this conversation?
• Does this require a subgroup or individual to generate a proposal?

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.)