2022-10-19 Meeting notes
- Jeremy Huff
- Ingolf Kuss
Date
Attendees
- Jeremy Huff Mikhail Fokanov Ingolf Kuss Marc Johnson Florian Kreft Ankita Sen @Maccabee Levine Tod Olson Jenn Colt Zorian Sasyk Ian Walls Jakub Skoczen Owen Stephens Raman Auramau
Discussion items
| Time | Item | Who | Notes |
|---|---|---|---|
| 1 min | Scribe | All | Ingolf Kuss is next, followed by Maccabee Levine |
| - | TCR Board Review | All | No news. |
| - | RFCs | All | No news. |
| 1 min | Things FOLIO could do better | All | |
| 10-15 min | Technical Council Sub Groups Updates | All | Ingolf and Tod went over the Pain Points page and worked it into the Goals & Objectives page. Tod wants to wrap up this week. Translation subgroup didn't meet. Breaking Changes: Ankita started working on the RFC. Will send it by the end of next week. New subgroup "Improve the TCR process": Marc Johnson volunteers to participate. |
| 5 min | Spring Boot 3.0 | All |
Although we don’t recommend it for production, you can try Spring Boot 3.0 milestones today to see how hard it will be to migrate your project.
Today: Jeremy: It seem we have not come to a conclusion of this topic. Marc: We have to signal that it is not our business right now. Let us wait for Craig. There is a technical decision. We could make that ... for any of the modules. ... It means that the TC does not need to have an official stance on it. We do not have policies in place. Vijay comes in here... I find it mind-boggling how Spring Boot handles this. You have to upgrade a new version of this and that and to a major version of Spring itself which is not yet supported. This goes beyond my mind. Jeremy: I can not follow this, either. It does seem like we can offer some specific guidance. We have to defer this discussion. |
| 5-10 min | Tools/Dependencies Versions | Previous:
Today: | |
| 5 min | Retrospective on the ADR Process |
Notes: There are some candidates on the Doodle Poll. | |
| 10-20 min | Officially Supported Technologies and Mod OA | A discussion, explored by Marc Johnson in this slack post (https://folio-project.slack.com/archives/C02HP10PPGB/p1665740976370339), should be had concerning the role of Officially Supported Technologies in our new module evaluation process. Notes: Marc: Jeremy did a review of mod-oa. Zak did not understand the reasoning, because Groovy is not on the supported technology list. Without changes in our policies, there will be no way to pass mod-oa to pass the acknowledgement process. Shall we stay with this policy ? The supported technologies list was written as a backend for the module acceptance criteria. Now we are talking about how to make changes to modules. So now it also applies to existing modules. There are numerous modules that are currently written and use technologies that are not on the supported technologies list. We do need to answer the "new modules" list. Jeremy: It is clearly a discrepancy. If mod-oa would be submitted again based on the same technologies it would be rejected again. It would have to be completely rewritten. Jeremy: mod-oa passed on the specific criteria; it did not fail the acceptance criteria because of the technology it uses. Technologie that we have experiences with are on this list. If you do implement a technology that is not on this list.,...This is intended to be a guideline. Marc: Most folks are familiar with Java and Spring. ... Folks want to be at the Flower releases. ... Do we want to be so restrictive ? We can just add Groovy and Grails to the list. That would solve the issue immediately. But support and boot tooling issues are then unresolved. And: Where do we stop ? Do we add all new technologies in ? Mikhail: My concern is the programming language. Maybe a beautiful new team comes to FOLIO and developers in Fortran. Then the new team disappears again. My opinion is we have to stay with Java. We could add Groovy to this list. But it would be beneficial not to make this list too long. Jeremy: The process we have designed allows for people to make judgement calls. It is workable. That will potentially lead to some conflict at some time. It will produce disagreement but I do not necessarily see this as a bad thing. Macabee: We need literal processes. Identify what are absoulzely core requirements. Tod: Don't put the burden on the operations teams. On the other hand I do want there to be some flexibility. A nice compromise: Accept Java, Grails, NodeJS, Perl & Python (or something like that). Owen: We should not discourage those who are already enthusiastic. ... We will have an issue of support. It is the number of people that we have. We have seen that multiple times. A statement of a vision of the technical environment. Let us improve the overall situation of managing FOLIO. We always have bigger problems here. If we add one more technology, we will talk about this topic again. Ingolf: I support Tod that we should ask the dev ops teams what burden that puts on them if we add a new technology. We should go step by step, for now only inquire about Groovy and Grails. In my opinion, adding these technologies does not put more work to the sys ops folks, because they are development tools. Jeremy: Jason Root is very lassé faire about this. He just puts it in a container. And he does not think about compute costs. But a hosting provider will be very concerned on hosting costs. Marc: From a centralized build operation perspective: The dev ops folk did that years ago, there is nothing new to do. The other thing is the system operation. Some hosting containers build from source and do not use Docker containers. We need to make life easier for all of these people. Marc: We should add Groovy, it is a practical thing to do. There are at least two non-TC groups that are discussing this. How do we get more people willing to build things for FOLIO. There is another group from Julie Bickle. ... Some of the challenges will go away naturally. Then the project overall wins and the challenge goes away. Then we could be more lassé faire. But right now we don't have a way of distinguishing: must be in the middle of FOLIO, might be added later. It might take years to do this. But people know that right now it is not sustainable. Form the chat: Jakub: Why don’t we add Groovy/Grails to the allowed list? Owen: They were added to the project before the module acceptance criteria / process was in place Owen: I think we tipped over from “recommending" to "requiring" when the TCR process was formulated but that change was perhaps slightly hidden by this fact Ian : If we wanted FOLIO to be written in a single language, and present as a fully integrated system to users, we should just abandon the 'microservices' concept and embrace the monolith. Tod: Those are two different concepts that do not need to be combined. Marc: Ian, we effectively decided to go homogenous when we said all UIs must be stripes based and backend must be Java. As Tod says, the deployment strategy is related yet separate to that. I would like to emphasise that the group working on a desirable future state for FOLIO and the CC capacity challenges group both want to make it easier for system operators to customise and to shrink the centrally owned and strongly governed stuff. Tod: ++Owen: How do we make FOLIO a success, given the context. Owen: That's a sunk cost at this point because it already works. From Owen Stephens to Everyone. Unless you remove mod-agreement, mod-licenses as well. Jakub: Grails is still JVM so purely from the operations point of view there is less risk. Assuming the modules are well documented and follow similar patterns in terms of access to infrastructure. 10:59:26 From Tod Olson to Everyone: There's also different tooling that is needed for our QA processes. 11:00:26 From Owen Stephens to Everyone: I want to add one other specific comment around the question of flexible interpretation of guidelines is that if we are going to have some degree of leeway to interpret the criteria then why not do this on the basis of exceptions for excluding things rather than including things - that is we should have a policy that assumes inclusion rather than exclusion 11:01:35 From Tod Olson to Everyone: Nice framing, Owen. 11:04:05 From Owen Stephens to Everyone: To just pick up on the point about the development language etc being independent to sys ops - I understand that, but if we can get away from the tyrany of the Flower release then we can worry less about some of the minutiae of modules as we don't have to 'accept' them 11:04:59 From Owen Stephens to Everyone: And I think one of the reasons the Flower release is attractive because people want some 'easy' option for running Folio | |
| Topic Backlog | |||
| 20 min | All | Previous Notes: TC charter has been updated recently, how would the TC like to review it? Jeremy Huff Was it written by TC or by someone else? - Craig McNally It was written by TC? Craig McNally Let's create a draft version, discuss it, communicate to other councils before publishing Tod Olson A comment to Guiding Principles .... (smth that should be explicitly stated as a GP) - Tod will add a comment to the doc Some conversation followed.. some comments were added to the doc itself Review and comments from TC members are welcome After review, what will our rewrite process be? Suggestion: make a subgroup to handle the rewrite. What's the value of continuing the review in TC as a whole? Would provide a general summary of feeling about the current charge. Useful onboarding, or better to onboard with a revised charge? Seems like a subgroup has formed: those who have actually commented Decision: will continue with review, try to be quick and then hand to a subgroup Notes: Jeremy: This needs to be either a new subgroup or an individual charge. After we have identified what needs to change we need to ... (initiate actions). Marc: We need to continue to review. ReviewGuiding Principles:Need some revision per above, make these clear as they are what we go to when we are uncertain. Motivation review:Much language needs to change: relationship with PC is different, TC does not do resourcing, "platform" is a dubious term now. Structure and Composition:Much of this is redundant with FOLIO Governance Model. Should refer to that document, and retain only those items that supplement that document. Responsibilities:What does "own architecture" mean? When we reviewed a year ago, concluded we were not doing this well. There are some abandoned blueprint documents. Do we think we are still responsible for this? Yes. The purpose of TC is to set some constraints or shared agreements about how the platform develops. TC does not have many options for enforcement, want compliance. Might affect how we approach the architectural guidance. Opposing view: approach as agreement and consent rather than enforcement and compliance. Giving teeth or power to the councils balances the weight of more powerful community members, like a check and balance. One challenge for the councils is that some voices have made decisions and councils have to retroactively accept these decisions. This creates a disincentive to talk to the councils as they may disagree. So incentive is to do first and ask permission later. Define processes, etc.: need to be clear about project requirements v dev team domain Maintenance of Contributor licenses, etc., CoC, etc.: Many of these seem to be for CC Out of Scope: need to update the audience for these bullet points, broader than PC. Key deliverables:Much language inconsistent and out of date, some things up in discussion and may change radically. May need two phases: short term immediate changes, then long term after other discussions resolve. Architectural blueprint - have provided but need to update the deliverable. RFCs: need to add ADRs | |
20 min | WOLFcon Hot Topics | All | An overview was provided of the "hot topics" at WOLFcon. It seems clear that the TC ought to be involved in these discussions/efforts; what is the best way to participate?
Notes: |
| How can/should the TC weigh in on the architectural impact of new modules? | Introduce the topic
| ||
| Optimistic Locking interfering with batch update in inventory | Conversation started in slack:
Topic has been addressed. Core team has agreed to implement as separate API that disables optimistic locking. See also Bulk Operations redesign, different issue but seems related. | ||
| Ease of Installing FOLIO | All / Ian Walls | From last week:
Today:
| |
| Revisiting FOLIO Governance | All / Ian Walls | Slack discussion: Revisiting FOLIO Governance | |
Action Items
- Craig McNally investigate a calendar to track long term TC responsibilities