Minutes of DA Meeting 2023-04-26

Attendees:

• Paul Baker paul.baker@infitx.com (PB)
• Pedro Barreto pedrob@crosslaketech.com (PSB)
• Miguel de Barros miguel.debarros@infitx.com (MdB)
• Jason Bruwer jason.bruwer@coil.com (JB)
• Tom Daly tdaly61@gmail.com (TD)
• Johann Foley johannes.foley@sybrin.com (JF)
• Sam Kummary sam@infitx.com (SK)
• Michael Richards Michael.Richards@infitx.com (MR) (Chair)
• Jane Stroucken Jane.Stroucken@infitx.com (JS)

Apologies:

• Godfrey Kutumela godfreyk@crosslaketech.com (GK)

Absent:

• Aung Thaw Aye AungThaw.Aye@thitsaworks.com AT
• Warren Carew Warren.Carew@infitx.com (WC)
• Greg McCormick greg@frms.io (GM)
• Paul Makin pmakin@mojaloop.io (PM)
• Simeon Oriko simeonoriko@gmail.com (SO)
• Justus Ortlepp justus.ortlepp@gmail.com (JO)

Agenda:

• Issue 101: Failures on CI/CD builds due to Blue Oak License on License Checks (MdB)
• Issue 96: Clarifying Mojaloop Release Contents and release criteria/procedures (TD)
• Issue 102: Enable 2-factor authentication for all Mojaloop GitHub users (SK)
• Draft DA Charter (MR)
• AOB

Minutes

• Issue 101 (MdB)
  • OK with the license itself.
  • Other option is to downgrade dependencies
  • Or find an alternative
  • JF: can lawyers check that dependencies are OK?
  • SK: same question. Looks like we have access to consultation.
  • MdB: if we have access, they should check all our other licenses.
  • JF: are builds failing now? MbB:Yes, our workaround is to force versions. This is OK short term, but won't work long term.
  • MdB: if no resolution in acceptable time, DA will make a temporary determination of compatibility with Apache 2.0 license
  • PSB: can we check the rest of the list for compatibility? SK: yes, for non-Apache licenses
  • PB: are there any other licenses that we should check at the same time? MdB: can't think of any; but SK should do a quick check.
  • JF in chat: Chatgpt thinks it's compatible licenses: Who needs a lawyer? The Blue Oak Model License is a permissive open-source license that is intended to be an alternative to existing licenses such as the MIT, BSD, and Apache licenses. The Blue Oak License version 1.0.0 was released in 2018. The Blue Oak License is generally considered to be compatible with the Apache 2.0 license. This means that code that is licensed under the Apache 2.0 license can be combined with code that is licensed under the Blue Oak License without any legal conflicts. Both licenses are permissive open-source licenses that allow for the use, modification, and redistribution of software. However, it's always a good idea to consult with a legal expert to ensure that your specific use case is compatible with the licenses in question.
• Issue 96 (TD)
  • I thought we left it where SK would take a shot at defining what constitutes a release and the processes around it.
  • Should we start again?
  • This is a comment for v15.
  • SK: shares a checklist
  • SK: for future releases we use this template.
  • TD: good starting point. Can we prepend:
  • What is in the release?
  • What's the process and criteria for things getting into a release?
  • TD: thinking of the charts repo: how do items get included or excluded?
  • TD: who are the release managers? What's the thinking on whether something is in or out?
  • PSB: shouldn't this also be product? MdB, SK: agree
  • SK: some items have been excluded because they don't have automated testing...
  • SK: I hope to take the role of Release Manager. Execution rests with the team, but DA/TGB can make policy on how to make decisions on inclusion/exclusion.
  • TD: what if we wanted to exclude the charts repo in V16. What are the steps that would be taken?
  • SK: we will keep product and DA involved.
  • PSB: this is always about who's the product owner? If it's of a technical nature, then the product owner is the DA.
  • JB: this highlights a missing role: release manager. They co-ordinate between the various stakeholders and ensure that everybody's interests are accounted for. Not sure about DA as product owner: where there are multiple teams, workstreams and artefacts, a manger is needed
  • PB: example is not a good one: refactors happen all the time, and if you have one, you want to feel empowered to do it. There are code owners for each repo, and they should be responsible. And we would deprecate rather than remove. Who is the code owner: MdB, SK, Vijay.
  • JS: a question: TD is asking for a process. Shouldn't that be in the charter?
  • MdB: this is a product discussion, not for the DA. Should be for the product owners.
  • PSB: to do proper release management, we need release planning. MdB: PI planning is that. PSB: there are problems which are not product problems, but engineering problems. Who should own the engineering problems?
  • JB: it's not clear what the process for choosing what changes should go into the codebase. We think they should all be traceable to a PI planning. But there are unplanned changes. so there are multiple changes, some planned and some unplanned.
  • MR: we have to have workstreams separate from releases.
  • SK: DA can set inclusion standards and criteria, but inclusion can be done by workstream leads and code owners.
  • TD: whatever we decide, we need to write it down crisply. We need to have a discussion somewhere to decide what's in a release.
  • JB: this is in my and SK's remit. Open Slack channel to put together a draft process.
• DA Draft Charter (MR)

Actions:

• SK: get opinion on Blue Oak license. Will respond on attorney timeframe and report back. High priority.
• MR: document proposed course of action and circulate to TGB.
• JB: open a Slack channel and co-ordinate the draft definition of a process for definition of the constituents of a release.
• All: return to discussion of issue 96 next meeting