Tod Olson : Working through the pain points doc. To be coherent from the original doc with many contributors. Some points intertwined so will be bulky. Some themes emerging, i.e. improving documentation, module boundaries, storage handling, API design. Determine what items to discuss at WolfCon. What items can we take action on.
Zak Burke Microservices theme comes up a lot, but we use FOLIO as a system. Consider deployment as a whole, instead of pieces being designed narrowly. Consider the balance when we design.
Tod Olson Agree. We've designed around user-facing records instead of efficient processes.
... pause in discussion to end of meeting
Translations
Zak Burke Set agenda for the group, doodle poll. Getting it launched, not stuck. Possible first meeting next week. An architecture has already happened, are we happy with it, or define an approach in an RFC first. First meeting will define subgroup goals.
Radhakrishnan Gopalakrishnan Final stage, need to merge it. No GitHub permissions to do so yet. Craig will be doing a ticket to get the TC write access.
Marc Johnson Just ask on dev-ops channel, less effort than a ticket.
#1 AES proposal
VBar Can close this, settled a while ago. Just didn't go through the merge steps.
Marc Johnson Briefly discussed last week but needed more discussion. It's a historical doc, not really AES anymore (it's pub-sub, which has been superseded).
Check in on where the formation of the Elasticsearch/Opensearch working group... Do we want to add this to our subgroup page for tracking/update purposes?
Craig McNally Was subgroup formed? Do we want to track?
Marc Johnson CC did not form a working group. Discussed a week ago Monday. Agreed it should be a cross-council group. Will ask CC at their next meeting on Monday.
define "breaking change" in a subgroup? adjust definition of done? adjust release cycle to accommodate upgrade testing? Try to get Oleksii Petrenko 's input on this in the near future?
Craig McNally we had discussed subgroup for breaking change, come up with definitions
Zak Burke I posted notes to slack, there was a discussion. Lots of ways to list a module's dependencies. What should semver respond to. May be operational concerns (i.e. Java dependency), is that a breaking change affecting major version number. Wanted to form agreement. Haven't done that yet.
Zak Burke Hardest part is to figure out how to enforce constraints. Merges causing conflicts. How to surface it so more people are aware.
Jakub Skoczen Should we consider external dependencies infrastructure as part of this?
Zak Burke Yes, or if not we need a different way to surface those changes. I.e. when you run the UI in a browser there's technically no dependency, but the libraries that compile modules together has a Node 14 dependency. Where do we put that info if not part of the module itself. If not part of semver. It's less important that we come up with a precise definition of semver, compared to how we let people know of dependencies. Multiple audiences for whom a change might be considered breaking. For example, do we want an 'operations' number in addition to the one 'major version' semver number. Need some way of documenting it so people are informed.
Jakub Skoczen Agree. Better definition of how to make changes known. If language is strict then we have less understandings. Related, we constantly fall behind with infrastructure, don't have a good policy that would encourage it. Have raised it in meetings. We make updates for a reason: more functionality or performance. Don't want to be on Java 8 for the next 10 years. Should be tracking at least the last LTS.
Zak Burke If we had a policy that we should use the last LTS, when that expires, do we reflect that in the semver major version.
Jeremy Huff For goals: do we want to use semver to track those types of changes or not. If the group decides not, then is group also on the hook for how we disseminate the other changes. More useful to the project if we answer both.
Zak Burke They can be answered separately. As long as we do both. Ok with several narrow RFCs.
Marc Johnson For semver we're talking about at least two versions. Recent changes don't care about module implementation version, only interface version. So have to talk about both. Agree with concerns about operational. In scope of this group, even if the group kicks it out later.
Craig drafted goals on subgroups page.
Marc Johnson How both operational and breaking changes are communicated. And how people should operate in order to not break things, maybe as follow-up topic.
Zak Burke Agree, hoping to define the "what" now and the "how" after. Can't just commit something, do some communication process. Also what is part of the API: okapi interfaces, java or node version, etc. Some operational, some functional. If two breaking changes are made without a release in between, does the number bump twice. Define whether version is bumped at release or pre-release.