Tomas Fredberg (Ericsson)
Participants reviewed the TSC representatives who have put their names forward thus far.
Companies HPE, Intel, AMI, TietoEvry, Kubermatic have named a TSC representative.
Therefore, ODIM has formed a TSC with 5 companies represented and any vote of 3 can ratify a decision .
TSC then proceeded to call for a vote to ratify the Technical Charter, which was discussed last week.
TSC approved 5 votes +1 to ratify the Technical Charter, no disapproval, no abstain
Note: we agreed that we would vote in the chat window and capture save the chat for records of votes.
Moved on to discussion of Pull request process- i.e how do we go about submitting and approviing code changes.
We have a github setup for the project and will use Git Issues to post proposed changes and Pull Requests for actual code submissions
We discussed that bigger changes would warrant a "one pager" document proposals on what is the rationale, purpose, high level implementation ,impact etc of the proposed changes.
How would we capture them and archive them?
Jonas proposed the using Git Issues but Alex did point out that we can always save on the wiki major feature or subsystem proposals and ultimately use GIT Issues to officially submit.
Small changes, with little impact can be done with much less overhead or process-
Developer can create a Git Issue- opens a Feature Branch, complete an implementation, make a Pull Request- Reviewers will review the Pull Request
Discussion around the visibility of the Feature Branch and how this impacts collaboration...
We created a page to capture the process : ODIM Review Process
We made the point during this working session and open debate that this process can evolve and we can agree as a TSC to refine it to make it workable for our use
Discussed how major features might well be "sandbox" development at first to mitigate stability issues and once code is reviewed and tested , then code could be submitted in increments as is deemed feasible.
May need multiple maintainers to cover major areas of the code. Need at least two maintainers so that coverage is maintained when folks are absent. Discussed possibly agreeing on 3 maintainers for each major subsystem.
Question about whether we should have 1 or multiple repositories for the code base. HPE seed code will be put into 1 repo to start.
We can certainly create multiple repositories. Need to decide pros and cons of one or multiple.
For example, subsystems could each be in its own repository.
How does this impact CI/CD build pipeline? There can be a separate build for each repo.
Jonas indicated that he is happy to share maintainer responsibility but everyone needs to come up to speed on the code to have the necessary understanding of the code structure.
Alex suggested that at least 2 to start are from the company that submitted the seed code. new maintainers can be approved based on experience and can be reviewed on a periodic basis
Need to decide the period and precise process and document as we go.
Jonas has been testing CI/CD workflows. When someone merges code , it invokes a build/test workflow through Git Actions.
They have some basic unit tests for HPE seed code that we can start from now.
Alex proposes we go with this for now.
Jim Baker suggested we create a poll for TSC Chair soon. We can use the Concordiate (sp?) poll tool.
We agree this would be good but ALex suggested that we are small enough right now and keep it informal for now. As we grow we can take this up but keeping it lightweight and collaborative for now seems to make sense. Louis agreed we could do it this way for now.
Louis suggested that he create permissions for active participants in the Github space.
Who wants to be an Admin? Jonas suggested that all TSC members could have admin status.
Meeting ended at 9: 14 PDT.