2022-06-22 Meeting notes

Jeremy Huff  is next, followed by Marc Johnson 

Zak Burke took notes last week for Jeremy

All

All

Technical Evaluation Process Subgroup: Radhakrishnan Gopalakrishnan Technical Evaluation Process Subgroup had a retrospective, they will have an update next week

Technical Council Goals/Objectives: Tod Olson Gathering pain points have been a blocker for Technical Council Goals/Objectives, hopes to have an update next week

Translation Subgroup: Zak Burke Nothing to report on Translation Subgroup, Craig McNally asks how we can move this forward. Jeremy Huff suggests reaching out to the community to find a champion to take ownership of the subgroup. Tod Olson Urges that we make time for this, to ensure that FOLIO supports non-english speaking communities. Marc Johnson provided some context, stating that KnowledgeWare is building FOLIO in the Middle East. He points out that this has resulted in a different version of FOLIO running in these communities. Zak Burke we need to manage technical concerns of communities who have concerns that are specific to their use cases. Jeremy Huff maybe an RFC is the right option for this?

FOIO Scope Criteria: Marc Johnson this group had a soft reset last week. Once their activity was presented to the CC and the PC it revealed that there was a lack of alignment in the goals for this group. They are discussing what their goals are currently.

Mark Veksler there has been no movement of the AWS Hosting Costs SUBGroup

Radhakrishnan Gopalakrishnan No updates on New Developer OnBoarding

Radhakrishnan Gopalakrishnan No updates

Olamide Kolawole 

Introduction of the subject - brief presentation: bumped to 2022-06-22 [Presentation Attached to this page]

Olamide Kolawole presented on the current state of Kafka in FOLIO and why we should reconsider it. 

Marc Johnson This is very important topic, but we need to be very careful to understand that this proposal is intended to address the limitations of pricing models of certain hosting providers, and not the limitations of Kafka. He also mentions that there are two separate topics, one is the scalability of our current approach and the other is the security of our current approach. These should be addressed separately.

Olamide Kolawole points out that finite partitions is a limitation of kafka

Jeremy Huff we should address the request that an RFCs is created for this, and that we need to decide if this should be one or two RFC. Craig McNally agreed that the scope needs to be carefully defined.

Marc Johnson We choose to either solve the whole world and we get stuck, or we solve one thing and our solution is not globally efficient. When decisions are made it takes a long time to enact them. Some people have suggested that we make more iterative smaller decisions that can be enacted more quickly. If we are going to do an RFC let's separate the goal (reduce the number of partitions per tenant) and the proposed solution.

Olamide Kolawole is happy to take ownership of an RFC on the scalability issue.

Notes from previous meetings:

• The question was raised in slack by Marc Johnson 

How do we make tool version decisions? I’m asking because FOLIO is currently on Java 11. I imagine it could be prudent to move to 17 (the next LTS) at some point, and it seems that the #stripes-architecture group made the decision to move the project from Node 14 to 16 recently.I don’t think there is an equivalent group for the back end. How do we envisage the project making these kinds of decisions?

• Some feedback was given, but it's probably worth discussing as a group.
• Should we form a sub-group to define policies/processes?
• there was some discussion and some comments; in general, the problem is relevant for the backend, frontend, and infrastructure. Agreed to make a placeholder for next week, and once again contact in search of volunteers
• Make a page with the tools and versions for Morning Glory as a starting point.
• tools-and-versions page created by Radhakrishnan Gopalakrishnan 

See DR-000003 - Morning Glory support period

Previous Notes:

• Julian Ladisch : see background/context for the motivation. 
• Zak Burke : we should have an ADR for designated and LTS, but not one for Morning Glory in particular. Jeremy Huff , Radhakrishnan Gopalakrishnan , Mark Veksler : agree
• Radhakrishnan Gopalakrishnan : this amounts to a support policy; Tod Olson : yeah, and also intersects with support policy recommendation that has been made; does the TC really get to make this decision for MG? 
• Mark Veksler  : also looking for guidance from security group about when to do/not do security investigations ; LTS designation should be done by PC, not TC; there are cost implications. Guidance from PC was to revisit this in late 2022. 
• Julian Ladisch : security fixes need to be evaluated for criticality and how long they should be backported. Want a decision WRT how far back security issues should be backported?
• Mark Veksler we don't have an LTS now, but have "current and previous" guidance and should stick to that for now.
• Owen Stephens fixing security updates to a flower release, vs to the release of the component itself (stripes, raml, spring) seems awkward.
• Craig McNally : Put this to a vote next week? 
• Ingolf Kuss : what feedback are you looking for from sysops? Julian Ladisch endorsement, which can come via lazy consensus
• Craig McNally but is this our decision or the PC's? Marc Johnson but it's landed in our court for now. All: let's briefly discuss moving it forward next week. 
• Jeremy Huff : if not deciding about MG specifically, TC certainly can/should be involved in the general criteria for LTS designation.

Today: 

Jeremy Huff Which versions are LTS should be decided by the PC and how we handle LTS should be handled by the TC

Marc Johnson The individuals who originated the proposal should put together a cross council group to address this

Zak Burke We should not make a decision that is specific to morning glory, but a general decision about LTS support

Julian Ladisch The LTS topic will take longer to discuss, this ADR was intended to get a quicker decision for morning glory

Zak Burke A longer and more generalizable discussion now will save us time in the future 

Marc Johnson Agrees that we should have a policy concerning security back ports, but this may be something which should be managed by the POs (Oleksii Petrenko) and not the security group.

Tod Olson Whoever drives this forward should get in touch with those who wrote the LTS recommendation. 

Craig McNally asked Julian Ladisch if he would want to drive cross council discussion on LTS. Julian Ladisch said yes.