#acumos-meeting: Acumos TSC

Meeting started by bryan_att at 13:05:12 UTC (full logs).

Meeting summary

  1. Agenda (bryan_att, 13:05:31)
  2. Planning Release (bryan_att, 13:05:54)
    1. Jamil: presents release plan proposal deck (bryan_att, 13:06:37)
    2. Nat: How to handle new projects, to allow them time to design in the release. (bryan_att, 13:14:41)
    3. Nat: model training and license mgmt projects need to be started or they will miss release B (bryan_att, 13:16:05)
    4. ... propose to identify PTLs now (bryan_att, 13:16:27)
    5. Jack: propose that we include design work in release A for these new projects (bryan_att, 13:19:12)
    6. Bryan: we will need to address the projects/repos structure first before PTL assignment, since the current list would likely not fit the current proposal on the wiki at https://wiki.acumos.org/display/AC/Acumos+Architecture+Mapping+to+Repos+Jira+etc (bryan_att, 13:24:18)
    7. Bryan: the proposal looks more compatible with waterfall process projects; I am unsure if it will fit an agile process which includes test/QA and requirements verification with the stakeholders (Community/Project committee). (bryan_att, 13:25:38)
    8. Jack: describes current development practice which is more agile (bryan_att, 13:27:05)
    9. Jack: code is developed on master and release is cut periodically, e.g. weekly (bryan_att, 13:28:42)
    10. Jamil: since we have significant startup code we can focus on the testing with a limited design time on new projects (bryan_att, 13:30:04)
    11. Jack: proposal for 1st release name is "Athena" (bryan_att, 13:30:30)
    12. Manoop: re code freeze, recommend this be later at RC date to enable more development time, if the features being dev'd are fewer; we can also use the proposed code freeze date as a gate for high/critical defect correction only (bryan_att, 13:32:46)
    13. #info Jack: this points to a question about open source in general: how much release functionality is just controlled by contributions over time, and how much is release functionality planned in advance (bryan_att, 13:34:21)
    14. Bryan: most large open source do have a specific release plan phase in which new features are agreed (bryan_att, 13:35:42)
    15. Manoop: PTLs can control which code goes in per the relation to a feature ID (JIRA issue). Any code that does not make the release will be deferred to the next release. (bryan_att, 13:37:34)
    16. Jamil: we also have to agree on the maintenance plan for releases, how long do we support e.g. via maintenance versions (bryan_att, 13:38:20)
    17. Scott: may be able to provide some input from the LF release engineering (bryan_att, 13:40:09)
    18. Anwar: want to be sure there is adequate time for integration testing (bryan_att, 13:41:25)
    19. Bryan: testing should be continual, with unit, subsystem (integration), and even full system level test being done before the code freeze (bryan_att, 13:42:18)
    20. Jack: the integration team will need to prepare a plan long before integration start, so they are ready and can use tools e.g. robot to automate testing (bryan_att, 13:43:17)
    21. Pantelis: should we consider cloud-native support as a high level requirement, and how will we consider these re the current code, e.g. will they significantly impact the current code and thus should be deferred to release B, etc (bryan_att, 13:44:26)
    22. Jack that's where M1 is critical, and the discussions between M1 and M2 would address that; in this 1st release case M1/M2 are the same and that puts a challenge on large feature proposals (bryan_att, 13:45:47)
    23. Pantelis: if we do see new requirements agreed that have large changes on the code (e.g. architecturally), they will in this 1st release be not possible and will be deferred to the next (bryan_att, 13:47:05)
    24. Jack: we can separate M1/M2 if we need to consider the release plan for new features, to decide if they are in A or B (bryan_att, 13:47:46)
    25. Scott: Vanessa (release eng team) can provide some input on what's typical (bryan_att, 13:50:23)
    26. Manoop: if M1 results in a feature proposal that by M2 is agreed in scope terms, the team can then develop what is possible given that scope and defer the rest (bryan_att, 13:53:02)
    27. Jack: 1st time thru the process we will be figuring out the test processes e.g. re the nature of this project vs others (bryan_att, 13:54:18)
    28. Jack: goal for today was to get agreement on M0 (bryan_att, 13:54:44)
    29. Scott: the plan can evolve during the release (bryan_att, 13:55:11)
    30. Jack: call for motions to approve (bryan_att, 13:55:23)
    31. Nat: recommend approval (bryan_att, 13:55:35)
    32. Ofer: are we separating M1/M2? (bryan_att, 13:55:51)
    33. Nat: we can modify to gove some time as needed (bryan_att, 13:56:08)
    34. Vote resulted in no objections to the proposed Release plan and M0 date (bryan_att, 13:57:23)
    35. AGREED: The release plan proposal and M0 date are agreed (bryan_att, 13:57:47)

  3. Committee Lead nominations (bryan_att, 13:58:09)
    1. Currently Anwar has self-nominated for Architecture; need nominations for Community and Security (bryan_att, 13:59:27)
    2. for PTLs, the wiki page https://wiki.acumos.org/display/TSC/PTL+Nominations shows the current proposals and we need others to sign up as candidates - we can have two or more and vote (bryan_att, 14:01:22)
    3. Jack: recommend that we add a Release Manager to the TSC committee lead roles (bryan_att, 14:02:08)
    4. Nat: re the agenda, #B is (LF env refresh) is planned for 5/22 (bryan_att, 14:02:47)
    5. Nat: re the Platform-OAM repo, we need to add an additional committer for maintenance in advance of the project startup (bryan_att, 14:03:42)
    6. AGREED: - another committer can be added to Platform-OAM as requested by Nat (bryan_att, 14:04:24)


Meeting ended at 14:04:31 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. bryan_att (46)
  2. collabot` (3)


Generated by MeetBot 0.1.4.