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