15:01:55 #startmeeting C-release milestones 15:01:55 Meeting started Mon Jan 25 15:01:55 2016 UTC. The chair is debrascott. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:55 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:01:55 The meeting name has been set to 'c_release_milestones' 15:02:49 goto link? 15:02:55 https://global.gotomeeting.com/join/977976589 15:03:19 sorry did not publish agenda 15:04:13 Let’s start with something like what milestones, worked OK if any 15:05:30 #topic what went well/and not well, short list of where improvements need to be made 15:06:14 #info Fatih Degirmenci 15:06:57 #link https://wiki.opnfv.org/releases/brahmaputra/release_plan 15:07:51 #info need to start earlier with project definition (whose participating) 15:09:08 #info milestones A & B were to close together 15:11:45 #info some dependencies were unclear early on and needed to be clarified to all projects earlier 15:12:18 #info example: projects did not understand the need to create installer plugins until quite late 15:13:49 #info in some cases these were not a lack of planning but lack of visibility to new requirements with regard to supporting installation of new features. 15:15:59 #info tool chain & installer & pod processes were being developed at same time that feature projects needed to understand how to work with them 15:18:01 #info should infrastructure & tool chain be run through a separate release process from feature integration & release work? 15:20:03 #info CI toolchain is already separate from the release 15:21:35 #info tool chain can be used because they are tagged by release but they are not part of the release itself 15:23:23 #info milestone C, need more detailed and better checklists 15:23:50 #info example when do the plugins have to be done 15:24:15 #info need to allow more time in backend for testing and integration 15:25:34 #info need earlier understanding of integration, deploy & test so things like scenario definition needs to be earlier 15:26:55 #info writing of code can be done in parallel or even after these definitions are completed 15:28:25 #info need to look after C-release regarding how it is working to have pre-upstreamed code included 15:28:53 #info need to enable more plugins, even for things that are not oss 15:31:53 #info make sure we always use reproducable upstream code 15:33:06 #info challenge aligning to upstream project development cycle 15:33:25 #info need to pick baselines early 15:34:34 #info Trevor Cooper 15:41:05 #info need to define scenarios much earlier 15:41:53 a=want to join 15:41:57 b= scope 15:42:06 c=scenario's defined 15:42:28 d=plugin's implemented 15:42:35 e=code freeze 15:42:41 or something like that... 15:42:46 #info identify which installler you intend to operate with 15:43:53 #info have plugin for the installer ready by D: emphasise it 15:44:41 #info need checklists for milestones to be clearer 15:44:44 some questions that pop to mind: 15:44:59 When do the plugins need to be ready with foundation components being deployed 15:45:06 When does the feature need to work 15:45:20 When do the test cases need to be started/running/frozen 15:46:12 The idea will be to limit the issues with the installer tools, once it works on one it should be "less complicated" to get working on another. 15:46:42 Pharos labs need to be running earlier 15:47:10 #info pharos lab resources identified at milestone C 15:48:09 #info need stable environments available for feature projects to use for dev, test, & integration work 15:48:24 #info need installers supporting consistent model 15:50:19 #info latest and stable need to be supported by projects so we know which branch that installers really work, 15:51:37 #info use “promotion” process to move installer stable up to where other projects use it knowing it is reliable 15:52:36 will we be able to automate that for B-onwards? So Jenkins will push stable versions of branches to labs (not working on latest/branch)? 15:53:00 ChrisPriceAB: we need all installers to be onboard 15:53:09 ChrisPriceAB: and we need clear definition of test loops and scopes 15:53:18 #info: separate checklists for each type of project earlier, notably intstallers are very different 15:53:34 yeah, good points fdegir getting there though... 15:53:40 ChrisPriceAB: so when we test something, we must be able to say it works in some level of confidence 15:53:55 ChrisPriceAB: the testing we do now is for reporting at the moment 15:54:07 ChrisPriceAB: we need to convert it to something we use for deciding what's good and what's not 15:54:40 yep. dev stable may be 2x full runs. stabl/stable may be 4x. or something like that, you are the experts not me. :) 15:54:55 and we should have daily and weekly loops 15:54:58 So we need process requirements for installers, a different set of process requirements for test, and a different set of requirements for features 15:55:27 we can do promotion without branching 15:55:42 we just tag the version that worked last night 15:56:08 and adjust the CI for feature projects to run their integration/tests based on this tag 15:56:56 #info what do we need to have functioning before freezing code? 15:57:05 #info keep this at scenario level 15:58:00 #info project box based on scenarios 15:59:41 #info need to keep quality on master (today’s C relase) 16:01:24 #info get CI process defined/communicated better 16:01:55 #action Chris & Debra to draft proposal on C release criteria 16:02:17 #action Debra to set next meeting 16:02:31 #endmeeting