2022-06-29 Meeting notes

Marc Johnson is next, followed by Steffen Köhler 

All

All

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

---

I attended the PC council update meeting earlier this afternoon.The topic of LTS for flower releases, that we discussed yesterday, was discussed.Folks from the TC started working group (@mdg and @Harry) shared that the LTS model had been discussed and partially agreed upon. However the decision of when that policy came into effect was reviewed late last year and deferred till the end of 2022 due to the believe that ongoing feature development was a more important aspect of development over long term bug fixes and support for multiple year old flower releases.It did lead to a really interesting follow up conversation about how complicated this policy is in practice:

• the folks building the modules (and who owns them) do not report to the PC / TC and those are the folks impacted by this policy
• the hosting providers have a role to play in support (and are arguable ultimately responsible to their customers)
• whether we support flower releases as a whole or support a module

Folks believed this question was important and complicated to answer well. And that a review was needed.It was acknowledged that practically speaking, groups like the Support SIG (and release managers etc) use the policy of supporting the current and one past 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.