2025-03-12 Eureka & TCR

Date

12 Mar 2025

Attendees

Discussion items

Time	Item	Who	Notes
1 min	Scribe	All	Jenn Colt is next, followed by Florian Gleixner 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.
*	TCR process adjustments for Eureka	All	Will clarifying our charter impact how we go forward? Review is in our current purpose, will it still be going forward? TCR process doesn't feel as broken as RFC TCR related to charge in that it is how we have chosen to try and keep the community aligned and as a way to arbitrate disputes on technical matters Community would need to be prepared if TCR were to go away What about rejected modules For Eureka: What needs to change Designating application Fit and design has been excluded previously, so why would we have it for applications? Scale up module Dev teams could debate where the module should live - in what application Partitioning of stuff already reflects the teams and will probably continue to Modules were original unit of composition for FOLIO, now we either have two units of composition or modules are just a technical thing and applications become unit of composition Should the TC accept applications or only modules? Soon flower releases will be defined by applications Take module requirement wording and add version for applications But not weigh in on what module goes in which application Application: valid descriptor- evaluators need to know how to validate is the application new? if a module that is part of that application that is approved does that mean the application is approved or does the application have to get approved first? how do we indicate an application is included in a flower release? where modules get bundled together into functionality, which may be more in the PC realm technical requirements of application descriptors are in support of the functionality bundle Modules Piece of code so still review Have to be attached to applications because that is how Eureka works Might be good to enumerate the roles and responsibilities we have questions about and figure out where those responsibilities practically/actually live, related to future review of our charter Are application reviews redundant when we are already reviewing the modules? In order for the module to get in, an application that hosts it has to be in as well Before this PC were evaluating an "app" What should PC/TC evaluate? What about when we have an application that is in FOLIO and new module is added to it and we haven't accepted it then what happens to it? Future discussion: Permissions - teams had to adjust to new naming conventions so there are guidelines there - should they go into the criteria? at least point to them - links are already in the criteria System users - new modules should follow new approach of declaring system user and privs in the module descriptor rather than including logic to create system users pub sub has been deprecated and is on the way out (eventually), in criteria say that we shouldn't add new pub sub stuff, use kafka directly instead (alignment with OST instead?)
-	Zoom Chat		11:38:47 From Day, Kevin to Everyone: Thank you. That helps me understand. 11:50:21 From Jenn Colt to Everyone: Devops yells at the team 11:52:37 From Jenn Colt to Everyone: Happens all the time on dev envs or so it appears Marc Johnson:👍 11:53:24 From Marc Johnson to Everyone: Replying to "Happens all the time on dev envs or so it appears": Indeed, that may inform our opinion of the effectiveness of module evaluation 11:54:54 From Jenn Colt to Everyone: No one evaluates the helm charts or whatever. Ok, I’ll stop now! 11:59:36 From Julian Ladisch to Everyone: The permissions requirements for Eureka are already in the criteria: https://github.com/folio-org/tech-council/blob/master/MODULE_ACCEPTANCE_CRITERIA.MD?plain=1#L113