Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Date

...

Discussion items

TimeItemWhoNotes
1 minScribeAll

 Taras Spashchenko will take notes today.

Reminder:  Please copy/paste the Zoom chat into the notes.  If you miss it, this is saved along with the meeting recording, but having it here has benefits.

1 minTCR Board Review

All

Nothing new

5-10 minLiaison Updates
  • CC: Maccabee Levine
    • No meeting this week
  • PC: Tod Olson
    • Announcement of Poppy delay
    • Update from the Application Formalization subgroup - charter is in draft, PC voiced concerns about getting re-architecting work into the Roadmap, and whether Application Formalization and subsequent re-structuring would affect ability for apps to interact.
    • Meeting planning: scheduling topics and meetings around holidays, how to schedule for Asia/Pacific participation; SIGs going to written updates and quarterly PC meetings.
  • RMS Group: Jakub Skoczen
  • Security Team: Craig McNally
    • The findings from the Prisma scans. There was another about 15 umbrella issues that got logged last week. The group  triaged maybe about a third of those




5 min

Technical Council Sub Groups Updates

All

Quick updates only.  If we can't find volunteers for groups, we'll need to add the topic to our backlog and address it during dedicated discussion sessions.

Craig McNally : We need to start a conversation in Slack to see if was can get any movement on the "Communicating Breaking Changes".

1 minDecision LogAll

Previous Notes:

  • DR-000038 - PostgreSQL Upgrade to 16 created by Julian Ladisch . Detailed analysis has been done to check if any of the breaking changes will impact FOLIO. There are a couple of unknowns, where it can't be easily verified if FOLIO is affected.
  • Craig McNally we want to move to PG15 but the Q release may be too soon, so the recommendation might be the R release.
  • Taras Spashchenko Kitfox is working on an env with PG14 and PG15 and will run a series of tests to exercise the platform. 
  • Marc Johnson are we trying to make a decision today? We're past the point where the decision should've been made for the Q release. it's not sufficient to just search and test FOLIO core code as implementers run custom code.
  • Jeremy Huff knowing the results from the actual testing would help to inform the decision : We should probably hold off until ramsons for PostgreSQL

Today:

    • See OST topic below.
10-20 minRFCs

All


RFC Process Improvements:

  • Craig McNally : Last week I was very close to getting the abstracts for the four application formalization related RFC's ready. We would let folks give feedback and then I would present them on today's call. I addressed many of the questions, but I realize that folks probably haven't enough time to see my revisions, but I can certainly go through this.
  • Zak Burke :
  • Still need to update RFC metadata to reflect new/adjusted statuses, etc.No update on the 0004 Date-time values must comply with IETF RFC-3339. There are objections from Julian Ladisch making just API Services RFC 3339 compliant. My inclination is to move it to the next stage with the proposal to just make the change at the API surface level, not make any comments about storage.
  • Craig McNally presented his RFCs one by one. 
    • TC voted to move these RFCs forward
    • Craig McNally: I'll make the changes about backward compatibility and the bounded context of the database access saying that FQM is out of scope.
    • Maccabee Levine Marc Johnson will add their comments to the RFC PR
  • Craig McNally: We need another RFC to update the metadata retroactively to reflect the new or adjusted statuses.
  • RFC "Ask for an implementation timeline" is still open

Notes:

15-25 min

Officially Supported Technologies

All

Standing agenda item to review/discuss any requested or required changes to officially supported technology lists

  • Check in on progress... does anything else require attention?
Today

Quesnelia Officially Supported Technologies discussion:

  • React ^18.2 is correct (Zak Burke)
  • Zak Burke will check RTL support for React 18
  • Cypress ^9.1.1: Talk to the people who use it and find out what they would like to do
  • Update Grails from 5 to 6:
    • Craig McNally: I would rather make the statement that we need to go to 6; otherwise, the longer we wait and deliberate and evaluate and so forth that means it's less time for developers to do the actual work.
    • Marc Johnson: 100% completely agree

Moved to the next meeting:

  • Formalize decisions on the following.  Quesnelia is the last chance to upgrade to avoid running unsupported versions:
    • Postgres 13 → Quesnelia 
    • Grails 6 → Quesnelia
  • Postgres 15 → Ramsons
    • Wait until we see the result of Kitfox testing
  • Attempt to move Quesnelia from DRAFT → ACCEPTED → ACTIVE since the relevant milestones have already passed.
1 minUpcoming MeetingsAll
  • - Topic TBDDo we expect to have enough in attendance to make meeting worthwhile?Cancelled.
  • - Regular TC meeting
  • - Topic TBD
NAZoom Chat

Marc Johnson  to  Everyone 11:04 AM
AFAIK the Tri-council group has not finalised it’s charter yet

Jenn Colt  to  Everyone 11:05 AM
Correct

Marc Johnson  to  Everyone 11:11 AM
We discussed PostgreSQL 13 vs. 15 was on a Wednesday

Marc Johnson 11:11 AM
Last Wednesday IIRC

Tod Olson 11:11 AM
My recollection also.

Jenn Colt  to  Everyone 11:27 AM
Maybe they were reacting to my confusion

Jenn Colt  to  Everyone 11:42 AM
I’m out

Maccabee Levine  to  Everyone 11:43 AM
Not a quorum

Tod Olson  to  Everyone 11:49 AM
Shall take up Quesnelia OST for Postresql and Grails? I may be proved wrong, but that scope seems straightforward.

Owen Stephens  to  Everyone 11:59 AM
At least affected: Agreements, Licenses, Open Access (not in Flower release), Serials (new for Quesnelia)

Marc Johnson 11:59 AM
And service interactions?

NAMeeting Summary with AI Companion
Meeting summary for Tech Council (FOLIO) (11/20/2023)
Quick recap
The team discussed various topics including the delay in the poppy announcement, an update on application formalization, and potential impacts on app interactions. They also scheduled topics for the upcoming period, recognized Julian's contribution to the security team, addressed breaking changes in the Postgres version 15 upgrade, and emphasized the importance of individual development and release cycles for applications. The team also discussed handling multiple RFPs in parallel due to bandwidth constraints and dependencies, and the importance of including "backwards compatibility" in the scope statements for their systems.
Summary
PC Meeting: Notes, Tasks, and Updates
Craig confirmed that Yakov had taken notes in the previous meeting and assigned the task to Taras for the current one. Tod discussed three main topics in the PC meeting, including a poppy delay announcement, an update on application formalization, and concerns about potential formalization impacts on app interactions. The team also discussed scheduling topics for the upcoming period and balancing interaction with the Sigs. The charter was drafted but not finalized. The team reported progress on the security team and recognized Julian's contribution. They also addressed the issue of breaking changes in the Postgres version 15 upgrade, deciding to hold off until the Ramp phase. Zak provided an update on the RFCs, noting he was working on addressing feedback, and identified a potential bandwidth issue regarding the number of RFCs in progress.
Application Formalization and Management RFCs Presented
Craig presented two draft RFCs regarding application formalization and management. The first RFC defined an application and its components, while the second focused on application management aspects such as registration, creation, and management. Craig suggested submitting the first RFC before the second one, with the second targeted for submission in the coming weeks. He also discussed the current state of application development, proposing changes to UI bundles and the need to address intermodal linking, static asset loading, and dynamic loading and unloading of application bundles. Craig emphasized the importance of these changes to allow individual development and release cycles for applications. He also discussed adjustments to the user experience, inspired by a comment from Maccabee, with an estimated timing of mid to late December. Lastly, Craig proposed the introduction of the concept of boundary context to align with application boundaries, addressing cross-module database access, data ownership, and data integrity.
Application Formalization Process and RFP Handling
Craig outlined the sequence and timing of the application formalization process and sought feedback on the next steps, which included addressing outstanding comments and possibly advancing to the preliminary review stage. Jenn confirmed the process allows moving forward to the next stage after a meeting, while Marc suggested voting on all application-related matters to streamline the process. The team also discussed the complexities of handling multiple Request for Proposals (RFPs) in parallel due to bandwidth constraints and dependencies. They agreed on the need to vote on the RFPs quickly and move them to the RFC stage once written up, while also considering voting on them individually. Craig clarified Maccabee's scope question, indicating that the preliminary review stage was about nailing down the scope and general direction before moving forward.
RFC Development and Bounded Context Confusion
There was a discussion about the scope and development of an RFC related to database access issues. Maccabee raised concerns about the overlap between this RFC and another one concerning 'bounded context', and whether the former was meant to replace the latter. Craig confirmed that the RFC was still in progress and clarified that its scope did not include the 'bounded context'. Marc also expressed confusion about the distinction between the RFCs, but after further clarification, he agreed that they were separate issues. Craig suggested that if the matter needed further discussion, they could keep the 'bounded context' RFC in the preliminary review stage until it was sorted out.
Backwards Compatibility in Scope Statements
Marc and Craig discussed the importance of including "backwards compatibility" in the scope statements for their systems, particularly for the UI bundle and the UI bundles one. Marc expressed concern about the potential for systems to operate without any use of applications and the impact this could have on the definitions and operations of their modules. Craig agreed to incorporate this into the scope statements. They also touched on philosophical debates that could arise from decisions based on the boundaries of applications, and how these decisions could impact system operations.
Project Progress and Upcoming Meeting Concerns
Marc and Craig discussed the progress of a project, with Marc expressing his concerns and questions. Craig suggested that Marc leave comments on certain project documents so he could address them. The issue of the upcoming Wednesday meeting was raised, with concerns about attendance and whether there would be a quorum. Despite this, they decided to move the project forward based on verbal agreements to update the scope statements. Marc and Craig voted in favor of moving the project components to the next stage, with Maccabee also voting in favor.
Projects, Comments, Improvements, Official Support, Timing, and React
Craig discussed the decision to move forward with certain projects and changes related to backwards compatibility. He asked Maccabee and Marc to add comments to the RFC for tracking discussions and resolutions. Craig also highlighted the need for improvements in the commenting system and the progression of merged updates and RFCs. The conversation shifted to the upkeep process of officially supported technologies, with a particular focus on timing of activities and milestones. Craig suggested moving the project forward from draft to accepted, and then to active. Lastly, Craig asked Zak to confirm the relevance of the react and stripes 90 versions for queue.
Stripes, React, and Grail Upgrade Discussions
Zak and Craig discussed potential breaking changes in the 'stripes' project, with Zak confirming the need to resolve this issue by a tentative deadline next Monday. They also stressed the importance of third-party decisions before moving forward. A discussion about the version of 'react' and its dependencies occurred, with Zak needing to investigate further. The team agreed not to make any changes to test-related technologies without further investigation to avoid confusion among developers. Craig led a discussion about upgrading from Grail's 5 to 6 due to public support ending in June, with the team deciding to make a decision on this and other related upgrades as soon as possible, even if it meant dealing with potential consequences later. The team also decided to cancel the Wednesday meeting due to a small expected turnout.
Next steps
• Taras will take notes for the next meeting.
• Zak will discuss the date-time values RFC with Julian and try to move it to the next stage.
• Craig will update the scope statements for the RFCs based on the discussed concerns.
• Zak will check on the React and Stripes versions by next Monday.
• Craig will reach out to Yogesh for thoughts on the testing stack dependencies.


Topic Backlog

Decision Log ReviewAll

Review decisions which are in progress.  Can any of them be accepted?  rejected?

Translation SubgroupAllSince we're having trouble finding volunteers for a subgroup, maybe we can make progress during a dedicated discussion session?
Communicating Breaking ChangesAllSince we're having trouble finding volunteers for a subgroup, maybe we can make progress during a dedicated discussion session?
Officially Supported Technologies - UpkeepAll

Previous Notes:

  • A workflow for these pages. When do they transition from one state to another. Do we even need statuses at all ?
  • Stripes architecture group has some questions about the Poppy release.
  • Zak: A handshake between developers, dev ops and the TC. Who makes that decision and how do we pass along that knowledge ? E.g. changes in Nodes and in the UI boxes. How to communicate this ? We have a large number of teams, all have to be aware of it.  TC should be alerted that changes are happening. We have a couple of dedicated channels for that. Most dev ops have subscribed to these channels. How can dev ops folk raise issues to the next level of community awareness ? There hasn't been a specific piece of TC to move that along.
  • Craig: There is a fourth group, "Capacity Planning" or "Release Planning". Slack is the de facto communication channel.  There are no objections to using Slack. An example is the Java 17 RFC. 
  • Craig: The TC gets it on the agenda and we will discuss it. The TC gets the final say.
  • Marc Johnson: We shouldn’t use the DevOps Channel. The dev ops folks have made it clear that it should only be used for support requests made to them.
  • Jakub: Our responsibility is to avoid piling up technical debt.
  • Marc: Some set of people have to actually make the call. Who lowers the chequered flag ?
  • Craig: It needs to ultimately come to the TC at least for awareness. There is a missing piece. Capacity Planning needs to provide input here. 
  • Marc: Stakeholders / Capacity Planning could make that decision. Who makes the decision ? Is it the government or is it some parts of the body ?
  • Marc: the developers community, the dev ops community and sys ops are involved. For example the Spring Framework discussion or the Java 17 discussion. But it was completely separate to the TC decision. It is a coordination and communication effort.
  • Marc: Maybe the TC needs to let go that they are the decision makers so that they be a moderating group.
  • Jakub: I agree with Marc. But we are not a system operating group. Dependency management should be in the responsibility of Release management. There are structures in the project for that.
  • Jason Root: I agree with Jakub and with Marc also. Policies should drive operational/release/support aspects of Folio.
  • Jason Root: If the idea of “support” is that frameworks are supported, then of course the project should meet that.
  • Marc Johnson
    Some group needs to inform OleksAii when a relevant policy event occurs.
    These documents effectively ARE the manifestation of the policy.
  • Craig: This is a topic for the next Monday session.
  • Craig to see if Oleksii Petrenko could join us to discuss the process for updating the officially supported technologies lists.


Dev Documentation VisibilityAll

Possible topic/activity for a Wednesday session:

  • Discuss/brainstorm:
    • Ideas for the type of developer-facing documentation we think would be most helpful for new developers
    • How we might bring existing documentation up to date and ensure it's consistent 
    • etc.

...