13:05:12 #startmeeting Acumos TSC 13:05:12 Meeting started Mon May 21 13:05:12 2018 UTC. The chair is bryan_att. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:05:12 Useful Commands: #action #agreed #help #info #idea #link #topic. 13:05:12 The meeting name has been set to 'acumos_tsc' 13:05:31 #topic Agenda 13:05:54 #topic Planning Release 13:06:37 #info Jamil: presents release plan proposal deck 13:14:41 #info Nat: How to handle new projects, to allow them time to design in the release. 13:16:05 #info Nat: model training and license mgmt projects need to be started or they will miss release B 13:16:27 #info ... propose to identify PTLs now 13:19:12 #info Jack: propose that we include design work in release A for these new projects 13:24:18 #info 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 13:25:38 #info 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). 13:27:05 #info Jack: describes current development practice which is more agile 13:28:42 #info Jack: code is developed on master and release is cut periodically, e.g. weekly 13:30:04 #info Jamil: since we have significant startup code we can focus on the testing with a limited design time on new projects 13:30:30 #info Jack: proposal for 1st release name is "Athena" 13:32:46 #info 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 13:34:21 #info #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 13:35:42 #info Bryan: most large open source do have a specific release plan phase in which new features are agreed 13:37:34 #info 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. 13:38:20 #info Jamil: we also have to agree on the maintenance plan for releases, how long do we support e.g. via maintenance versions 13:40:09 #info Scott: may be able to provide some input from the LF release engineering 13:41:25 #info Anwar: want to be sure there is adequate time for integration testing 13:42:18 #info Bryan: testing should be continual, with unit, subsystem (integration), and even full system level test being done before the code freeze 13:43:17 #info 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 13:44:26 #info 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 13:45:47 #info 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 13:47:05 #info 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 13:47:46 #info 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 13:50:23 #info Scott: Vanessa (release eng team) can provide some input on what's typical 13:53:02 #info 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 13:54:18 #info Jack: 1st time thru the process we will be figuring out the test processes e.g. re the nature of this project vs others 13:54:44 #info Jack: goal for today was to get agreement on M0 13:55:11 #info Scott: the plan can evolve during the release 13:55:23 #info Jack: call for motions to approve 13:55:35 #info Nat: recommend approval 13:55:51 #info Ofer: are we separating M1/M2? 13:56:08 #info Nat: we can modify to gove some time as needed 13:57:23 #info Vote resulted in no objections to the proposed Release plan and M0 date 13:57:47 #agreed The release plan proposal and M0 date are agreed 13:58:09 #topic Committee Lead nominations 13:59:27 #info Currently Anwar has self-nominated for Architecture; need nominations for Community and Security 14:01:22 #info 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 14:02:08 #info Jack: recommend that we add a Release Manager to the TSC committee lead roles 14:02:47 #info Nat: re the agenda, #B is (LF env refresh) is planned for 5/22 14:03:42 #info Nat: re the Platform-OAM repo, we need to add an additional committer for maintenance in advance of the project startup 14:04:24 #agreed - another committer can be added to Platform-OAM as requested by Nat 14:04:31 #endmeeting