| Time | Item | Who | Notes |
|---|
| 1 min | Scribe | All | |
| - | TCR Board Review | | |
| - | RFCs | All | |
| 10-15 min | Technical Council Sub Groups Updates | | TC Goals/Objectives 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 |
| 1 min | Retrospective on the ADR Process | | Notes: - Scheduled for Friday Oct 28, 11:00 AM ET...
- People should add notes to the board ahead of that meeting.
|
| 1 min | Organizing our wiki space | | - 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 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 |
| 5 min | Spring Boot 3.0 | | - 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.
|
| 5-10 min | Tools/Dependencies Versions | | |
10 min | Officially Supported Technologies and Mod OA | | 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.
|