Skip to end of banner
Go to start of banner

2022-10-19 Meeting notes

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Date

Attendees 

Discussion items

TimeItemWhoNotes
1 minScribeAll

Ingolf Kuss is next, followed by Maccabee Levine 

-TCR Board Review

All

No news.

-RFCsAll

No news.

1 minThings FOLIO could do betterAll


10-15 min

Technical Council Sub Groups Updates

All


Ingolf and Tod went over the Pain Points page and worked it into the Goals & Objectives page. Tod wants to wrap up this week.

Translation subgroup didn't meet.

Breaking Changes: Ankita started working on the RFC. Will send it by the end of next week.

New  subgroup "Improve the TCR process": Marc Johnson volunteers to participate.

5 minSpring Boot 3.0

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

Today:

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.

5-10 minTools/Dependencies Versions

Previous:


Today:

5 minRetrospective on the ADR Process

Notes:

There are some candidates on the Doodle Poll.


10-20 minOfficially 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:

Marc: Jeremy did a review of mod-oa. Zak did not understand the reasoning, because Groovy is not on the supported technology list.  Without changes in our policies, there will be no way to pass mod-oa to pass the acknowledgement process. Shall we stay with this policy ? The supported technologies list was written as a backend for the module acceptance criteria. Now we are talking about how to make changes to modules. So now it also applies to existing modules. There are numerous modules that are currently written and use technologies that are not on the supported technologies list. We do need to answer the "new modules" list. 

Jeremy: It is clearly a discrepancy.

If mod-oa would be submitted again it based on the same technologies it would be rejected again. It would have to be completely rewritten.

Jeremy: mod-oa passed on the specific criteria; it did not fail the acceptance criteria because of the technology it uses. 

Technologie that we have experiences with are on this list. If you do implement a technology that is not on this list. This is intended to be a guideline.

Jakub: Why don’t we add Groovy/Grails to the allowed list?
Given that there are many modules using it

Owen: They were added to the project before the module acceptance criteria / process was in place
I think it is the case that we would see failures in a number of cases if we were to run the currently included modules through the same process as new modules
Not just on this basis

Marc: Most folks are familiar with Java and Spring.


Topic Backlog
20 min

Tech Council Charter

All



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.

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


Notes: 

Jeremy: This needs to be either a new subgroup or an individual charge. After we have identified what needs to change we need to ... (initiate actions). 

Marc: We need to continue to review.


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

WOLFcon Hot TopicsAll

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:


How can/should the TC weigh in on the architectural impact of new modules?

Introduce the topic

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

Optimistic Locking interfering with batch update in inventory

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.


Ease of Installing FOLIO

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

Revisiting FOLIO Governance

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

Action Items

  •  Craig McNally investigate a calendar to track long term TC responsibilities 
  • No labels