13:05:12 <bryan_att> #startmeeting Acumos TSC
13:05:12 <collabot`> 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 <collabot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:05:12 <collabot`> The meeting name has been set to 'acumos_tsc'
13:05:31 <bryan_att> #topic Agenda
13:05:54 <bryan_att> #topic Planning Release
13:06:37 <bryan_att> #info Jamil: presents release plan proposal deck
13:14:41 <bryan_att> #info Nat: How to handle new projects, to allow them time to design in the release.
13:16:05 <bryan_att> #info Nat: model training and license mgmt projects need to be started or they will miss release B
13:16:27 <bryan_att> #info ... propose to identify PTLs now
13:19:12 <bryan_att> #info Jack: propose that we include design work in release A for these new projects
13:24:18 <bryan_att> #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 <bryan_att> #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 <bryan_att> #info Jack: describes current development practice which is more agile
13:28:42 <bryan_att> #info Jack: code is developed on master and release is cut periodically, e.g. weekly
13:30:04 <bryan_att> #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 <bryan_att> #info Jack: proposal for 1st release name is "Athena"
13:32:46 <bryan_att> #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 <bryan_att> #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 <bryan_att> #info Bryan: most large open source do have a specific release plan phase in which new features are agreed
13:37:34 <bryan_att> #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 <bryan_att> #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 <bryan_att> #info Scott: may be able to provide some input from the LF release engineering
13:41:25 <bryan_att> #info Anwar: want to be sure there is adequate time for integration testing
13:42:18 <bryan_att> #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 <bryan_att> #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 <bryan_att> #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 <bryan_att> #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 <bryan_att> #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 <bryan_att> #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 <bryan_att> #info Scott: Vanessa (release eng team) can provide some input on what's typical
13:53:02 <bryan_att> #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 <bryan_att> #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 <bryan_att> #info Jack: goal for today was to get agreement on M0
13:55:11 <bryan_att> #info Scott: the plan can evolve during the release
13:55:23 <bryan_att> #info Jack: call for motions to approve
13:55:35 <bryan_att> #info Nat: recommend approval
13:55:51 <bryan_att> #info Ofer: are we separating M1/M2?
13:56:08 <bryan_att> #info Nat: we can modify to gove some time as needed
13:57:23 <bryan_att> #info Vote resulted in no objections to the proposed Release plan and M0 date
13:57:47 <bryan_att> #agreed The release plan proposal and M0 date are agreed
13:58:09 <bryan_att> #topic Committee Lead nominations
13:59:27 <bryan_att> #info Currently Anwar has self-nominated for Architecture; need nominations for Community and Security
14:01:22 <bryan_att> #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 <bryan_att> #info Jack: recommend that we add a Release Manager to the TSC committee lead roles
14:02:47 <bryan_att> #info Nat: re the agenda, #B is (LF env refresh) is planned for 5/22
14:03:42 <bryan_att> #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 <bryan_att> #agreed - another committer can be added to Platform-OAM as requested by Nat
14:04:31 <bryan_att> #endmeeting