2022-07-13 Meeting notes

 Ingolf Kuss takes notes today, followed by Maccabee Levine 

All

None; subgroup is forming related to TCR-9

none

All

• Translation subgroup:
  • Zak: starting to collect a group - doodle poll is under way
• FOLIO Scope criteria:
  • groups figures out what to exactly achieve. No changes.
• Tech evaluation: Tod Olson anticipates having more time to dedicate to this in the near future; will check in 7/20, and anticipate discussion on it at WOLFCon. 
• Technial Documentation:
  • Maccabee Levine and Ingolf Kuss will do a single server fresh-install doumentation (for Lotus)
• Need help from devops in order to figure out permissions and resolve some comments in the repo. Radhakrishnan Gopalakrishnan anticipates resolving comments on RFC PR #3 (localizing API backend messages). 
• i18n: Tod Olson suggests active recruitment but we don't know who to request. Radhakrishnan Gopalakrishnan may be able to assist. Zak Burke will repost recruitment request to Slack#general

• Nothing new open; RFC #3 discussed above. Radhakrishnan Gopalakrishnan will begin work with Olamide Kolawole on Kafka soon. 
• We have two approved PRs.
  • Localization API backend RFC.
    • Will be merged as is (Vijay will do that)
    • Who is responsible for managing the comments ? This has been a little muddy in the past.
    • We have to sort out the permissions (who can edit comments, who can merge). We don't want to have DevOps involved each time. We need to resolve the comments.
    • We did have a rough policy that the RFC proposer was responsible for making sure comments are addressed.
  • AES Proposal RFC. Put it on a future TC agenda.

• CC met and talked about FOLIO's capacity, run by third parties contributors. 
• Topics of elasticsearch and OpenSearch
  • In June, FOLIO switched from ES to OpenSearch, at least in the client
• How do we address licensing questions
• CC might ask TC for volunteers to talk about OpenSource licensing.
• Jeremy: Picking one seems porblematic, being agnostic is also problematic
• We like to have something which is database agnostic, like ODBC (Zak). But this is not realistic. To be pragmatic, we should say: We support postgres, elasticsearch, ...
• We did have conversation about Elastic vs. OpenSearch. We should refresh our memory.
• The prior discussion about Elastic is here: 2021-01-20 Meeting Notes
• Solr was the other option that was on the table, the other time
• If we did make a decision, we don't have a record of this.
• Elasticsearch changed the licensing model to make it difficult to Amazon to offer a service. But if you do not offer a service, than you would still be o.k. to do that. We are not offering a service, so we are o.k. with the license. 
• It boils down to a licensing problem. Can we trust the Elastic license ? Or do we go with an OpenSource solution and adopt OpenSearch.
• Jakub: It feels like we should support Elastic, but there is a licensing uncertainty.
• There is a distinction between the license for the client software and the license for the server. At the moment, it does not make a difference. But it might diverge in future.
• There is nothing that prevents someone from building a solution on the basis of Solr
• The change in the client is not an issue here. But if ES is being  officially supported, you don't want to change the client.
• If it is not the case now, then in some point in the future we might have a system that is not anymore compatible with Elastic
• Effectively, today, elastic search and open search are functional equivalent. Both parties intend that to change
  When we talk about support, we need to consider our ability to do so. There are other conversations about support and testing going on in the scope-criteria group because our current approach is unsustainable
• Jakub:  I think the infrastructure decisions is not something that can be made independently by development teams (e.g based on the needs of whoever is funding them) because they have impact on the entire system. If you want to build a house you can choose the architectural design you like but you still need to respect local building regulation.
  
  
• FOLIO has never made an official decision in favor of using containers – maybe it should.
• We already have diverging definitions of a FOLIO system in the world (cf. Harry in the PC meeting)