Page Comparison

Date

29 Jun 2022

Attendees

Discussion items

No outstanding action items Welcome .

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

Jeremy Huff : will we use ADR for answering questions like "What should receive long-term support?" Radhakrishnan Gopalakrishnan : still up for discussion. Marc Johnson : let's keep those separate; maybe there is confusion about the word "support", i.e. "supported technologies" vs "long term support for a given release".
Objectives: consistent use across teams, choose LTS versions, be timely WRT security issues, plan updates ahead of time
Julian Ladisch : there may be little/no benefit to enforcing consistency across backend modules given they are independent; Radhakrishnan Gopalakrishnan these are guidelines for an honor system; let's not get hung up on enforcement.
Olamide Kolawole would a non-java backend module be accepted today? Zak Burke given module acceptance criteria no. Group chat Ian Walls , Brooks Travis : this is unfortunate and may stifle community contribution.
Radhakrishnan Gopalakrishnan this has been left up for review, there were couple of comments. He is not sure if this is enough feedback. We will leave it open for more feedback.

Today:

See ADR-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.
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.
Later in slack from Marc Johnson :

This is the process that I was referring to at the end of the TC - Morning Glory (R2 2022) PO Bugfix and Hotfix Release Process: It is defined by the PC, Capacity Planning group, product owners and Release Manager for each flower release and describes how decisions are made about what is and is not fixed during the lifecycle of a flower release.

And from Kristin Martin in slack:

Good morning @here and I'm sorry I missed the last PC meeting due to illness. I am catching up in the notes and would like to clarify regarding the Long Term Release recommendations. The PC did endorse the work of the working group and that is documentation on the wiki here in the decisions log, which also provides a link to the original minutes from our discussion in January. It appears that our communications of that endorsement did not get out to across the project, so perhaps after making a decision, the PC should announce decisions to the other councils? If the Security Team from Tech Council would like to talk to me as part of that original group, I'm available.

Today:

Any updates here?

There are differing viewpoints for how ADRs should be used...

when they should be used
who creates them
what types of decisions are applicable

It would probably be helpful reach agreement and provide clear guidance on these

Time	Item	Who	Notes
1 min	Scribe	All	Marc Johnson is next, followed by Steffen Köhler	< 5 min	Review outstanding action items	All		1 min	TCR Board Review	All	5 min
Technical Council Sub Groups Updates	All 5-10 min	RFCs	All	1-2 min	Elections	All	The following were elected to the Technical Council: Jeremy Huff (Texas A&M) Jenn Colt (Cornell University Library) Florian Gleixner (BVB - Bibliotheksverbund Bayern (Bavarian Library Network)) Maccabee Levine (Lehigh University) Ankita Sen (Mainz University Library) Dr. Ingolf Kuss (hbz, Cologne) The new members join July 1.	Craig McNally welcomed the new members to the Technical Council! For those leaving the TC, thank you! Keep in mind that you can always continue to attend and participate	5-10 min	Tool/Dependency Versions	All	5 min	Morning Glory and Kiwi support periods	Julian Ladisch	Time permitting	ADRs and TC processes	All	. Jeremy Huff Asked if we should consider re-electing chairs at this juncture? Craig McNally suggested we would discuss the chair and liaison roles at the next meeting.
< 5 min	Review outstanding action items	All	No outstanding action items
1 min	TCR Board Review	All	No in progress or new review requests
5 min	Technical Council Sub Groups Updates	All	Chulin Meng advised that the technical decision making group aims to be finished in the next few weeks Zak Burke shared the request to be made to the community for working group members to help out with multi-lingual FOLIO tenants and translation of reference records Craig McNally encouraged new members to volunteer to organise this working group, even if they aren't familiar with the specifics of the area Marc Johnson advised that the scope criteria group is doing a soft reset and reconsidering what it is trying to achieve (the goals and scope). They are at the beginning of this process Craig McNally asked that the group brings back those goals to the Councils to validate alignment Owen Stephens asked if there was overlap between this group and the forthcoming App Store discussion Marc Johnson advised that members of that group will be going to the App Store meeting. Beyond that the groups haven't interacted
5-10 min	RFCs	All	Radhakrishnan Gopalakrishnan advised that there was a recent change to clarify some details of the translation of static values in the back end and that RFC should be ready to complete soon A retrospective was also conducted by Zak Burke Craig McNally Marc Johnson and Radhakrishnan Gopalakrishnan . This led to some minor changes to the process, which is now ready to be used for the next RFC
5-10 min	PC / CC updates	All	Marc Johnson advised that the Community Council are trying to identify what they can do to address the community development capacity challenges. And that the Product Council are starting a working group to review browser support (which browsers are supported? what does support mean?) Craig McNally advised that there needs to be TC or technical representation in that working group Owen Stephens advised that he is putting together a charter / scope document for this group Mark Veksler asked about whether we have guidance from the PC / TC about what has to be included in the flower release notes? Craig McNally advised that this should be part of the definition of done for each team Marc Johnson suggested that whilst we can put this guidance in place, it is challenging for the TC to enforce this, Oleksii has more power than the TC in enforcing those rules Owen Stephens suggested that the Councils do have sway in the community and they should put in place the policy guidance Mark Veksler suggested that we exclude modules that do not include breaking changes in release notes from the flower distributions Jakub Skoczen asked what the specific challenge is? Mark Veksler advised that there had been a module released without the Flower release notes being updated Jakub Skoczen suggested that there needs to be an explicit contract between the development teams and the release coordinator. And that this is also a failure in detecting the issue prior to production Marc Johnson advised that we need to make quick progress if we want to address this for Morning Glory Mark Veksler and Craig McNally agreed that we will include this topic in the next meeting. Oleksii Petrenko will
5-10 min	Tool/Dependency Versions	All	Radhakrishnan Gopalakrishnan advised that there has been no progress made since request the for feedback on the proposed process. Limited feedback has been provided.
5 min	Morning Glory and Kiwi support periods	Julian Ladisch	Jeremy Huff asked if we have a place to publish policies? Craig McNally advised they could be put on the wiki or on the dev website Marc Johnson advised that this was discussed in the PC last week. The working group brought their proposal to the PC in January, the PC accepted those recommendations, however they delayed enacting them until at least the start of 2023. That means that practically, the official, interim, policy is the per-flower release policy and process. And that there has been a lack of awareness that the PC has made this decision and that the security group weren't aware of the status of this policy Tod Olson suggested that there is a potential misalignment between the interim policy / process and the needs of the hosting providers Marc Johnson advised that the intermediary policy / process accommodates that by deferring decision making responsibility for what gets back ported to the release triage group, which includes representation from most of the major hosting providers Craig McNally suggested that the security group needs to engage the release triage group for decisions. Marc Johnson agreed that the security group identify security issues and advise the release manager and the release triage group about them.

Versions Compared

Old Version 3

New Version Current

Key

Date

Attendees

Discussion items

Action Items