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.
Vision statement vote postponed until consideration of various other documents/proposals being drafted by subgroups that involve contribution network, membership, resourcing
Subgroup: "Cultivating an active healthy software development contribution network"
Mike will polish and share the in a today, discussion at next CC meeting. GDoc comments welcome. Draft by @Mike Gorrell (lead), @Boaz Nadav Manes @spampell @Christopher Spalding, @Kirstin Kemner-Heek
Create some development streams for folio organizations.
Bulletin board of needs, roster of development orgs capable of doing development. Wiki so light, self-policing.
Maintenance of certain modules may be sponsored for period of time. Or, general support pool from community membrsr dues. Points system of module weight, to allocate support need.
Second tier support pool. Organization that has specific expertise, not day-to-day maintenance but things they are expert on.
Craig McNally asked for volunteers to help update the RFC process documentation and update the existing RFCs to include stub entries. None were forthcoming
Still need to do this
Craig McNally will reach out to RFC proposer to create stub wiki pages that refer to the github RFCs
Craig McNally asked about whether we could update the calendar page. Marc Johnson advised that we are waiting for a Trillium timeline. Craig McNally will follow up with Oleksii Petrenko about when the schedule might be published
The Security Team would like to add a new rule which emits a warning when //NOSONAR is used.
This is a mechanism which can be used to instruct sonar to ignore specific lines of code.
There are alternative (better) ways to do this which only tell sonar to ignore certain rules for specific lines/blocks of code, e.g. @SuppressWarnings("java:S4790")
I've been looking at the inconsistencies in the environment variable naming in Eureka, specifically with KeyCloak, and so I created a Story KEYCLOAK-53.
This had me thinking and wondering if we as the Tech Council may want to discuss naming practices regarding core functionality to make environment variables across multiple and within modules more consistent.
Has there ever been any discussion on environment variable practices and naming consistencies?
I'm thinking that this might be worth discussing. I can see this being relevant for special modules like Kong, KeyCloak, FQM, etc...
For KEYCLOAK-53, the Eureka team has adopted the "KC_*" prefix for environment variables which pertain to Keycloak (KC over KEYCLOAK for brevity). Similarly, KAFKA_*, and KONG_*, etc.
However, for folio-keycloak, some environment variables are used by the keycloak container. These expect the "KEYCLOAK_*" prefix.
As Julian Ladisch points out in the issue comments, KEYCLOAK_ADMIN and KEYCLOAK_ADMIN_PASSWORD have been deprecated, and should be replaced with KC_BOOTSTRAP_ADMIN_USERNAME and KC_BOOTSTRAP_ADMIN_PASSWORD instead. We will probably just use KEYCLOAK-53 to track this work.
Marc Johnson different languages have different rules for environment variables, for example using underscores.
Craig McNally at least at framework level, variables should be consistent
Florian Gleixner Environment variables shlould look the same during deployment. For example a container entrypoint can translate.
This should be discussed by the sysops SIG and then be discussed in a Wednesday meeting.
NA
Zoom Chat
17:10:25 From Jakub To Everyone: No updates regarding the RMS from me
17:19:17 From Maccabee Levine To Everyone: We could also start to round-robin this kind of thing in the same way we do notes, and TCRs. But thanks Josh!