/
2025-03-19 Eureka & TCR

2025-03-19 Eureka & TCR

Date

Attendees 

Discussion items

TimeItemWhoNotes
1 minScribeAll
Ingolf Kuss is next, followed by ?

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 EurekaAll

Previous Notes:

 Click here to expand...
  • 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?)

Today:

  • pub sub removal is planned for Trillium
    • add criteria in module acceptance criteria? But this point is no more needed after Trillium
    • Should be noted in OST page for Trillium.
  • Permissions:
  • 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
    • Should be in module acceptance criteria?
    • Creating users the old way using mod-users / mod-permissions will not work in Eureka.
    • Therefore this is a breaking change for existing modules
    • Should be well documented and communicated - Release Notes and architectural documentation for example.
  • Application
    • should application descriptor should be part of criteria
    • Different opinions. Concerns when modules are not accepted, but the application is for example.
    • Which application belongs a module or is it a new application is a design decision, that should not be part of the criteria?
    • Should we technically accept the application - it is just a descriptor?
    • Why should we accept a module, that does not belong to a accepted application?
    • We could start with a application review process with first acceptance criteria: has it a valid descriptor.
    • How do we handle different compositions of modules in applications or concurring applications? Do we have to define criteria?
    • If a module of an application is not accepted, then the module has to be removed from the application or the application has to be removed from the flower release.
    • Applications should be accepted by the PC
    • Should we change the template or the criteria? In the template, the deveoplers are forced to think about it, but it will not fail.
    • Relationships between modules and applications should not break folio.
    • Or easy: "Module has to be compatible with the Eureka platform" and add specific criteria when needed.
      • Then many other criteria should be deleted because they are included.
      • Specific criteria make life easier for developers and evaluators
      • Incremental improvement of criteria is OK
      • → Stick with low level criteria.
    • Another TC discussion will be needed to flesh out the action items / criteria
-Zoom Chat


16:06:54 From Craig McNally To Everyone:
Permissions naming convention

16:43:07 From Marc Johnson To Everyone:
I consider applications to be the technical manifestation of product decisions (at least until applications have technical constraints e.g. data sharing)
Maccabee Levine:👍🏻

16:44:04 From Marc Johnson To Everyone:
We’ve already chosen not to involve ourselves in the module design / boundaries topic (which is at least partly driven by a technical variant of Conway’s law)

16:56:51 From Marc Johnson To Everyone:
Taking that high level approach to the process, we should get rid of all of our criteria and just ask for a demo
Huff, Jeremy T, Maccabee Levine:😃

16:58:15 From Marc Johnson To Everyone:
The moment when Eureka becomes the FOLIO architecture is when the sunflower release passes the threshold set by the councils





Related content