Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
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
Previous 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?)
Today:
pub sub removal is planned for Trillium
add criteria in module acceptance criteria? But this point is no more needed after Trillium
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
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