2022-10-26 Meeting notes

Maccabee Levine is next, followed by Tod Olson 

All

No news.

No news.

All

TC Goals/Objectives

• Radhakrishnan Gopalakrishnan There is a near-final list, broken down by high-level buckets.

Translations

• No update.  Zak Burke will bring forward in next two weeks.

AWS Costs

• No one at TC today.
• Marc Johnson We're getting a free enterprise license for KubeCost ( RANCHER-495 - Getting issue details... STATUS )

Breaking Changes

• Jeremy Huff Draft of the RFC is coming along.  May be able to bring to TC next week.

Improve the TCR Process

• Jeremy Huff Will have an invite out today.

Craig McNally 

• Retro board: https://easyretro.io/publicboard/bk8DxfBbCeZIYL1pnsBPUN2xgYb2/a07d2c6b-754b-4446-8743-7f32f2911928

Notes:

• Scheduled for Friday Oct 28, 11:00 AM ET...  
• People should add notes to the board ahead of that meeting.

Craig McNally 

• Created an "Archived" section under "Meeting Notes", consolidated meeting notes older than 2022 there.
• Created an "Archived" section at the top level, started moving things there which no longer seem relevant.  We can review this together at some point, maybe deleting some things for good, or putting them back if they are still relevant.
• This effort is still a WIP.  Let me know if you have any input/ideas.
• Jeremy Huff We might want a TC Calendar event at regular intervals to archive.  Craig McNally did so, repeating in January.

Technical Skills in Demand page

• Craig McNally Still useful?
• Marc Johnson Way of of date.  Reach out to see if CC is using it.

Development Teams and Resources page

• Craig McNally Missing various links.  Archive?
• Marc Johnson Most folks refer to the module team responsibility page.  That page is more up to date.  This page shouldn't be TC as we don't organize people.  Ask Khalilah Gambrell about work on a new definition-of-done template.  We might be the home for the technical definition but not the list of teams.

FOLIO Architectural Blueprint Strategic Changes page

• Craig McNally Various parts no longer relevant.  Archive?
• Marc Johnson TC didn't action this stuff directly.  Some happened, mostly without the TC.  Tod Olson and Radhakrishnan Gopalakrishnan working on the list of objectives, and the lists will overlap.
• Craig McNally will archive.

All

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

• 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

Jeremy: It seem we have not come to a conclusion of this topic.

Marc: We have to signal that it is not our business right now. Let us wait for Craig. There is a technical decision. We could make that ... for any of the modules. ... It means that the TC does not need to have an official stance on it. We do not have policies in place. Vijay comes in here...  I find it mind-boggling how Spring Boot handles this. You have to upgrade a new version of this and that and to a major version of Spring itself which is not yet supported. This goes beyond my mind.

Jeremy: I can not follow this, either. It does seem like we can offer some specific guidance. 

We have to defer this discussion.

Today:

• Marc Johnson Left this for Craig McNally because a decision had been made outside of the TC to defer this decision until after Orchid.  So Craig has context.
• Craig McNally Meeting ~2 weeks ago about how do we handle it.  Decision made to hold off, see how Orchid goes before we make a decision about Nolana.  Maybe adjust support period for Nolana, or maybe backport the Java/SB upgrade to Nolana in a hotfix.
• Jeremy Huff The decision seems a type that PC should be able to offer guidance.  Could come up again, and the best way is not clear.
• Craig McNally SB not going away, and there's a misalignment of their release process and ours.  Just one tech in our stack, so this will happen again.  If TC has advice to give, that's fine.  But probably has to be case-by-case.
• Marc Johnson There was also a mismatch about policies.  By the time the conversation happened, it was past the point of decisions to upgrade tooling or not.  Who does TC expect to make decisions like this.  If it's delegated down to the tooling groups, i.e. Spring Force makes the Spring decisions, is that where we want to be?  If so we can remove TC from this completely.  How does this fit with Radhakrishnan Gopalakrishnan 's work with TC making decisions of tooling and supported versions?
• Craig McNally What are the supported tech, who keeps them updated, who decides what release they get into and misalignment with dependencies (security angle).  Happened too late to get it into Nolana.  Not sure if the TC can solve these related topics all at once.
• Radhakrishnan Gopalakrishnan Marc asked how relevant this is to our tools/frameworks/dependencies work.  Should take it through the paces and identify gaps.  This is a non-infrastructure component where the team is initiating the upgrade.  So need a plan/timeline to document.  Does it make sense to give it a try.
• Craig McNally Put responsibility on the relevant teams to stay up to date, knowing when new versions are available, and upgrading?
• Radhakrishnan Gopalakrishnan The change could come from any team.  Are they the ones who will make the decisions, or can that happen outside core platform team as well?  Looks now like any team can make/propose a change provided they have a clear reason and plan for doing so.  If we are serious about that policy, this might be our chance to give it a try, and give teams an answer.  If time is a concern then not.
• Jakub Skoczen Misalignment between release/support policies and what underlying framework does.  It would be risky to rely on the team to track this, since the team didn't.  Might not have the knowledge & insight to do so.  Do we expect teams to track that their tools will be supported?  Surfaced by coincidence.
• Craig McNally Who is responsible?  It makes sense for the individual teams to be responsible, at least for identifying that there's a new version, and alerting the rest of the community to help plan how/when to upgrade.
• Jakub Skoczen Not sure teams are aware of all the relevant deadlines.  Have to also make sure release manager/coordinator checks with the teams.
• Craig McNally May not be related to a deadline.  Just want to know when the new releases come out.  Slated for X date, raise it with the TC or release coordinator.  Then together come up with plans, depending where we are with our release cycle.
• Jakub Skoczen Agree teams should actively track.  Just they can't align those with FOLIO release dates as those change.
• Craig McNally Agree, teams don't have to be aware of FOLIO dates.  Spring and Vert.x monitoring teams, require them to keep track of tool dependencies and release dates, bring that to TC or release coordinator (TBD).  Up to TC or release coordinator to come up with the plan of how to upgrade.
• Jeremy Huff We shouldn't be releasing unsupported code.  If conflict between support and release schedule, support needs to win that conflict.  Tying those together will encourage all parties to be aware.  TC can clearly articulate that we shouldn't be releasing code outside of support windows.
• Radhakrishnan Gopalakrishnan We will have a list of libraries/dependencies, and the teams responsible for watching each and communicating when it's time to upgrade.
• Craig McNally Yes at least for the major ones.  If it's a shared responsibility there are pros & cons.  You expect someone else to do it and no one does.  Vs a single team knows it's on them.
• Marc Johnson Re Jeremy Huff 's point.  Right now interim policy is that a release will be supported until two releases' time.  That would mean tooling has to be supported for that whole window, and we don't know that.  We should talk through Radhakrishnan Gopalakrishnan 's proposal as a concrete starter for what we're talking about.

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

Today:

Jeremy Huff 

Marc Johnson 

A discussion, explored by Marc Johnson in this slack post (https://folio-project.slack.com/archives/C02HP10PPGB/p1665740976370339), should be had concerning the role of Officially Supported Technologies in our new module evaluation process. 

Notes from last week: 2022-10-19 Meeting notes

Today:

• Goal: reach a decision on this today.  If necessary, we can put it to a vote.
• Craig McNally Did we have consensus about adding Groovy/Grails to the allow list?
• Jeremy Huff Last week: Seems to be a lot of discussion about the Approved Tech List and its role in our evaluation.  mod-oa was build with a technology that has a presence in flower releases.  Propose that we do vote to change the list to approve the new tech in question: Groovy/Grails/Gradle.  Two modules already utilize it.  
• TC voted and agreed.  Jeremy Huff will make that edit.
• Marc Johnson Confirm that we're approving for both new modules and existing modules?
• Jeremy Huff That list only has an application to the new module evaluation process.
• Marc Johnson True until we talk about Radhakrishnan Gopalakrishnan 's list next week, so then it will relate to existing as well.
• Jeremy Huff Propose to defer the role of the list going forward to the new subgroup.  

All / Maccabee Levine 

What, if anything should we do with the Decision log in the Technical Designs and Decisions wiki space?  Is it worth consolidating those decisions with the TC's ADRs?  Should we cross-reference?  Clarify the scope of these decisions, and whether or not decisions should still be made/logged here?  

See discussion in #tech-council for additional details.

• Craig McNally Decision log left when Tech Leads group fell apart with new governance structure.  Are decisions still made or logged in that space?  Where does this lie in the backlog.
• Maccabee Levine Motivations are to have a single list of decisions, to build developer-buy in and solve the longstanding issues with what decisions TC has authority to make.  Also to know what we have to keep updated vs archive.
• Craig McNally By consensus, added to the middle/bottom of the list.

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

Marc Johnson 

Tod Olson 

All / Ian Walls 

From last week:

• Ease of installing/deploying FOLIO - Ian Walls , Marc Johnson , Jeremy Huff
  •  Primary task the Tc would take on by making FOLIO easier to get up and running. Would also reduce AWS costs so that the money coming from Membership groups can be flowed to other aspects of FOLIO. Tc is the best equipped group to decide on how to make installing and deploying Folio easier and cheaper.
  • Craig McNally - Brainstorming open ended session with Ian Walls and then discuss further before or after WOLFcon depending on the brainstorming session. Ian Walls and Tod Olson to frame the topics of discussion for the brainstorming. 

Today:

• Probably defer, but keep on the agenda so we don't lose track of this...

All / Ian Walls 

Slack discussion:  Revisiting FOLIO Governance 

• • Ian Walls - should be best discussed in cross council meeting possibly at WOLFcon. Idea to was bring this up at a high community level not necessarily the Pc or TC. Doesn't need to be on TC agenda next week. Aspects to be discussed at WOLFcon.
  • See also:  messages to PC and CC council channels