3/26 Notes:
A module depending on platform-minimal cannot be added to platform-complete.
platform-complete is a bad name and will go away, will be split into chunks with better names.
A module can only belong to one application in FOLIOs community platform. There might be other platforms.
We haven't yet formalized strategies how application composition and platform composition should work.
Flower release applications and the platform exists, though.
Do we want the one-application per module be added to the module acceptance criteria, or to the module approval template?
Violating this criterium will fail the reference environments, and currently a module has already been added to the reference environments when module approval gets requested.
Module acceptance criteria drafting:
- must belong to one and only one application with the FOLIO platform LSP - template and the criteria form
- Further description of how to accomplish this can be added later (github search?)
- should declare system user and privileges in the module descriptor rather than including logic to create system users
- Add to naming conventions of permissions link to current documentation: Permissions naming convention
- Maccabee Levine will do a first draft of these updates
https://github.com/folio-org/application-descriptors is deprecated, ends with Quesnelia, and will be archived soon.
Use these repositories for Eureka instead: https://github.com/folio-org/app-platform-complete/ – https://github.com/folio-org/app-platform-minimal – https://github.com/folio-org/app-platform-full/
Questions regarding Eureka adoption by the community. TC accepted Eureka unconditionally, CC and PC accepted Eureka and require some condition to be met otherwise the timeline should be reconsidered. There's no intention to completely reject Eureka.
Previous Notes:
Click here to expand...
2025-03-12 notes:
- 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?)
2025-03-19 notes:
- 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