2024-11-11 Meeting notes

Marc Johnson is next, followed by Ingolf Kuss

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.

Maccabee Levine

Tod Olson

Jakub Skoczen

Craig McNally

Jenn Colt 

• CC: Maccabee Levine
  • Lee Braginsky presented on dataset anonymization for Better Sample Data working group. Randomized data while maintaining patterns. Looking for 2 devs, mid-senior, familiar with FOLIO DBs, fluent with Java or Python and SQL, for a few months. A tool for libraries to run themselves to create the data set, test, make sure no sensitive data. (Or EBSCO can run.)
  • AWS Costs. $30K cap is widely communicated. ACRG is adding budget alarms to help with reporting. A cost chart from AWS console will be shared with ACRG twice monthly, for Shawn to report to CC. No plans for circuit breakers. Continued discussions of what is 'shared' infrastructure that community would fund, split conversations about this current FY budget vs planning for future FYs.
• PC: Tod Olson: Rolling Out of Prioritization process for the SIGs. Where does the community as a whole see the priorities?
• RMS Group: Jakub Skoczen: No updates.
• Security Team: Craig McNally: No updates
• Tri-council Application Formalization:   Jenn Colt
  
  • Group has paused while POs and App Interaction work on spreadsheet from Taras
  • Talking a bit outside of meetings about  sequencing,  can discuss during Eureka topic

• 11 Nov 2024 - Regular TC meeting
• 13 Nov 2024 - Dedicated discussion:  Topic TBD
• 18 Nov 2024 - Regular TC meeting
• 20 Nov 2024 - Dedicated discussion: Topic TBD
• 25 Nov 2024 - Regular TC meeting
• 27 Nov 2024 - Dedicated discussion: Cancel for American Thanksgiving?

All

• Discussion and vote on Go RFC
  • Discussion about voting rules. ... we are at full attendance now (11 members).
    • Ingolf Kuss: current voting rules are strange. I can understand that we need 50%+ of attendance to make a decision at all. But if attendance is only 7 people, it does not feel right that all but one need to vote with "yes" for something to get accepted. I propose that in this case, Slack votes should fill up the rest of the votes (for those, who could not attend).  Alterantively, a simple majority could be considered sufficient (in case of a low attendance, this does not feel right, either, though).
  • Slack voting- acceptable?
    • are there objections to having Slack voting ? ...
    • Jakub Skoczen: Let's discuss as part of a bigger process.
  • Jeremy Huff votes for TAMU as Jason's proxy.
  • Vote: 7 yes, 2 no, 2 abstentions.
  • Marc Johnson : Can we shedule a subgroup "new language adoption policy" ? We have no sufficient policy for mod-reporting or for any future Go module.
    • The static code analysis subgroup already deals with the Go-language.
    • Jeremy Huff: Multi-language support. The CI-CD pipeline. That is a big point of discussion when it comes to multi-languages support. There could be polcies that retroactively will apply to other languages.
    • Jakub Skoczen: Will we have a fixed policy that will not let us post an RFC (when a new language comes up) ?
    • Marc Johnson: A minimum thing that has to be satisfied (e.g. build tools). That could be the entire scope of the group. Is there a limit to the number of languages that we want to take on ? 7 ? 10 ?? Could be we have to deprecate one of the existing languages if another language comes in. That will not anymore be sustainable for the community.
    • Craig McNally: Usually the team supports the language. We should not make it easier to introcude new languages.
    • Tod Olson: What Marc outlined is the bare minimum of consideration. Most compelling in this instance were AWS costs.
    • Jeremy Huff: Would containerization (of the modue) make the concerns less ? You need to have a technology to build containers.
    • Jason Root : A spring language proposal of TAMU was turned down. It popped back up later.
    • Jenn Colt: We need a Wednesday discussion on this policy.
• Discussion of Eureka RFC
  • Marc Johnson: We need to switch policies if we adapt Eureka for the Sunflower release.
  • Julian Ladisch: The community wants to have claritiy. I am in favor of adopting Eureka for Sunflower.
  • Marc Johnson: Let's make a special case. Ditch the RFC process, ditch the module reviews if we adapt for Sunflower. Just make a decision in the Tri-Council / the community.
  • Marc Johnson: Release process for Sunflower starts in February. When is the last responsible moment for this decision ? We run out of time to make this decision. There is a lot of work to do to adapt it in Sunflower.
  • Ingolf Kuss: I find it more relevant to discuss when will be the end-of-support time for Okapi, than when will Eureka officially be supported. It is clear that one can run Eureka already now, if one wants to. The question of official support is not so crucial for those who want to change to Eureka as quickly as possible. But it is is crucial for those who have limited capacities to change their enviroment ti Eureka.
  • Craig McNally: We are talking about two releases of backword support. That means Okapi support will end with Trilium.
  • Ingolf Kuss: Not only the community reference environment teams have to be ready to adopt it in Sunflower, but also the Sys Ops and Implementers have to be ready to change their production environments at a certain deadline. I have not heard any readiness from this side.
  • Jenn Colt: Should we make an extraordinary procedure for the Eurerka adoption ? We should discuss in a Wednesday meeting.

Nothing new here.

Check Recurring Calendar...

• Nominations are open

17:09:14 Von Craig McNally an Alle:



relevant deadline for sunflower: Jan 24th



17:16:11 Von Marc Johnson an Alle:



If the TC has agreed, then I don’t need a meeting, only a clarification of the documented rules



17:16:50 Von Julian Ladisch an Alle:



Can we update the distributed configuration RFC with the outcome? https://github.com/folio-org/rfcs/pull/40/files



17:36:24 Von Jenn Colt an Alle:



I always assume it shows in order but maybe it doesn’t…



17:36:50 Von Maccabee Levine an Alle:



Replying to "I always assume it s..."







It does, but sometimes people put their hand down and back up.  Didn't see what happened here.



17:36:59 Von Jakub an Alle:



Thanks Marc, adding guidelines makes a lot sense to me and the process around Go could inform it.  I would be reluctant to set some hard limits on e.g the number of languages. I don’t think we will ever face having to apply those limits but they feel artificial to me.



17:38:51 Von Jakub an Alle:



Yes, for a high bar for adding nee languages ans new technologies in general. Strict but clear criteria.



17:38:53 Von Craig McNally an Alle:



To be clear, it's not a problem with Go, my objection is more about expanding the set of languages Folio supports for module development.



17:39:03 Von Marc Johnson an Alle:



I also believe we should do this for tech and other architecture aspects







However I think that’s scope for a different conversation



17:40:29 Von Marc Johnson an Alle:



Where I’m coming from is organisations like Spotify,







Initially they went down a polyglot route. Later they decided to default to Java and teams have to pass a high bar to deviate from that



17:40:54 Von Marc Johnson an Alle:



Yes, it’s me that states that Docker has never been officially adopted



17:42:12 Von Marc Johnson an Alle:



Containers only partially reduce the impact of some of the adoption



17:42:25 Von Craig McNally an Alle:



Reacted to "Containers only part..." with 



17:42:48 Von Craig McNally an Alle:



Replying to "Containers only part..."







This is the point I was going to raise - In the interest of time I'll lower my hand



17:42:48 Von Huff, Jeremy T an Alle:



 We hung in there though!



17:43:06 Von Jason Root an Alle:



Reacted to " We hung in there ..." with 



17:46:23 Von Craig McNally an Alle:



Replying to "Containers only part..."







Other areas which need to be considered include:  Security Footprint, impact on devops, impact on those who build from source, support (we recently had a very close call with a node.js module)



17:46:34 Von Marc Johnson an Alle:



Reacted to "Other areas which ne…" with 



17:48:35 Von Ingolf Kuss an Alle:



sorry , I lost connection :42 o'clock and I am back now.



17:56:09 Von Marc Johnson an Alle:



The decisions for dual support etc have to come after the decision to adopt Eureka



18:00:43 Von Tod Olson an Alle:



I need to drop for my next meeting. Thank you everyone for the considered conversation.



18:03:00 Von Julian Ladisch an Alle:



I disagree that there is too much work to do in the community reference enironments to adopt Eureka for Sunflower.

Review decisions that are in progress.  Can any of them be accepted?  rejected?

Currently there is a PoC, developed by Maccabee Levine, of a utility to catalog Github PRs that have been labeled with the "breaking change" label. We would like to get developer feedback on the feasibility of this label being used more often, and the usefulness of this utility. 

Previous Notes:

• A workflow for these pages. When do they transition from one state to another. Do we even need statuses at all ?

Stripes architecture group has some questions about the Poppy release.

Zak: A handshake between developers, dev ops and the TC. Who makes that decision and how do we pass along that knowledge ? E.g. changes in Nodes and in the UI boxes. How to communicate this ? We have a large number of teams, all have to be aware of it.  TC should be alerted that changes are happening. We have a couple of dedicated channels for that. Most dev ops have subscribed to these channels. How can dev ops folk raise issues to the next level of community awareness ? There hasn't been a specific piece of TC to move that along.

Craig: There is a fourth group, "Capacity Planning" or "Release Planning". Slack is the de facto communication channel.  There are no objections to using Slack. An example is the Java 17 RFC. 

Craig: The TC gets it on the agenda and we will discuss it. The TC gets the final say.

Marc Johnson: We shouldn’t use the DevOps Channel. The dev ops folks have made it clear that it should only be used for support requests made to them.

Jakub: Our responsibility is to avoid piling up technical debt.

Marc: Some set of people have to actually make the call. Who lowers the chequered flag ?

Craig: It needs to ultimately come to the TC at least for awareness. There is a missing piece. Capacity Planning needs to provide input here. 

Marc: Stakeholders / Capacity Planning could make that decision. Who makes the decision ? Is it the government or is it some parts of the body ?

Marc: the developers community, the dev ops community and sys ops are involved. For example the Spring Framework discussion or the Java 17 discussion. But it was completely separate to the TC decision. It is a coordination and communication effort.

Marc: Maybe the TC needs to let go that they are the decision makers so that they be a moderating group.

Jakub: I agree with Marc. But we are not a system operating group. Dependency management should be in the responsibility of Release management. There are structures in the project for that.

Jason Root: I agree with Jakub and with Marc also. Policies should drive operational/release/support aspects of Folio.

Jason Root: If the idea of “support” is that frameworks are supported, then of course the project should meet that.

Marc Johnson
Some group needs to inform OleksAii when a relevant policy event occurs.
These documents effectively ARE the manifestation of the policy.

Craig: This is a topic for the next Monday session.

Craig to see if Oleksii Petrenko could join us to discuss the process for updating the officially supported technologies lists.

Possible topic/activity for a Wednesday session:

Discuss/brainstorm:

• Ideas for the type of developer-facing documentation we think would be most helpful for new developers
• How we might bring existing documentation up to date and ensure it's consistent 
• etc.