18:02:56 #startmeeting tws 18:02:56 Meeting started Mon Feb 1 18:02:56 2016 UTC. The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html. 18:02:56 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:56 The meeting name has been set to 'tws' 18:03:01 #topic agenda bashing 18:04:31 #link https://wiki.opendaylight.org/index.php?title=Tech_Work_Stream:Main&oldid=40524#Upcoming_Meeting_Agendas the agenda for today 18:06:02 #info today we'll cover boron planning 18:06:25 #info two topics: (i) fast-phased approach for shorter releases and (ii) advisory group input on boron 18:07:09 #topic advisory group input for Boron 18:07:36 #link https://lists.opendaylight.org/pipermail/tsc/2016-January/004565.html 18:15:27 #info colindixon notes that there are (in his mind) 3 bins of asks: (1) is new features at the ~project-level, (2) another is ODL-wide issues, (3) is sort of meta-issues around network architectures etc. 18:15:54 #info examples of (1) are things like BGP add-path and/or aggregated logs/alrsm 18:17:50 #Info examples of (2) are things like [easier] upgrades between releases 18:22:02 #info (3) is stuff like better defining the role of ODL as VNF manager vs. controller vs. NFV orchestrator 18:22:11 #topic easier upgrades 18:22:52 #info easier upgrades were something that was the top prioirty coming out of the advisory group 18:26:48 #info specifically, not for third-party apps, but for the components released as part of a major ODL releases it should be easier for users to upgrade than what they're currently doing which is starting from scratch every new release 18:28:07 #info edwarnicke says that he thinks upgrades are complicated and it's going to take us a few tries to get it right, thus having a shorter release cycle is likely to give us more tries to get it right in the same period of time 18:29:09 #link https://docs.google.com/presentation/d/1IKI8DV3oqb1snJLCaK6lLvvCXCnpEolQ6Xp_Qlk6E8M/edit 18:29:55 #info colindixon and rovarga agree with this within caveats of how fast you can actually go, how much you can actually do in a given time window, etc. 18:31:10 #info skitt and vishnoianil comment that if it's true that most users are only upgrading every year (or every other release) that releasing faster might not help 18:32:26 #info they say this is true both because faster releases won't help them, but also because debugging upgrades requires input from users who would also need to test upgrades faster, which they might or might not 18:35:20 #info uri worries faster releases will potentially signal instability 18:35:31 #info edwarnicke presents his fast-phased approch with the diagram about the different branches 18:35:40 #Undo 18:35:40 Removing item from minutes: 18:35:53 #info edwarnicke presents his fast-phased approch with the diagram about the different branches (see slide 2 of the linked google doc above) 18:36:56 #info colindixon says other than the raw overhead (which skitt and rovarga pointed out), there is the issue of how many differnet branches a project will have to simultaneously maintain 18:37:07 #Info edwarnicke says it's all trade-offs, colindixon agrees 18:38:40 #info edwarnicke points out the primary advantage of this approach is that everyone is building against (likely stable) release artifacts so that people aren't running into SNAPSHOT-integrated transient breakages, but also don't have to wait for 6 months for new released artifacts 18:39:00 #Info skitt says in the end you'll see a piepline that is 6 months long, but emits a release every 2 months 18:41:14 * rovarga disagrees on that :-) 18:41:25 * rovarga has seen very creative developers :))) 18:43:43 #info edwarnicke, vishnoianil, skitt, etc. talk about the merits of faster releases, edwarnicke says that he finds that testing and other things are easier when you do less long releases more often 18:44:06 #info edwarnicke says there's only so much trouble developers can get in in 2 months 18:44:38 #info vishnoianil says this would need to support projects that wouldn't have any changes in a 2 month period, that should be faciliated 18:47:31 #topic planning how fast-phased would work 18:49:43 #info colindixon says one good part of this is that it starts offf with kernel having a 2 month release, protocols have a 4 month release, and apps have a 6 month release, which is a reasonable way to get our feet wet without risking everything 18:49:54 #info colindixon ask kernel project devs how crazy this looks to them 18:51:17 #info edwarnicke points out that one advantage would be that we could maybe eliminate milestones other than cutting RCs some distance before release, e.g., we no longer need API freeze since that's really for downstream projects 18:52:32 #info rovarga says that he doesn't see the milestones as mosty for downstream projects, they're also for internal project discipline 18:52:49 #info rovarga also says that this needs to be fleshed out a lot more before we can commit to it 18:54:35 #Info zxiiro asks how many branches everyone will need, edwarnicke, he, and colindixon agree there will be three branches per project (between stable and integration branches), that's in addition to branches for older supported releases 18:56:49 #info rovarga says we'd need to see this diagram for two full cycles (~12 months) before we'd understand what's going on 18:57:27 #info skitt, rovarga and others argue that we should abandon text-named versions, e.g., -Lithium or -Lithium-SR1, etc. 18:59:19 #info skitt aks if we would consider shipping every 2 months for ourselves, but only some of those are targeted for "customers" 18:59:52 #info colindixon says he had thought about that too, which is that we might make only some releases public, e.g., 2 per year 19:01:29 #info LuisGomez had brought this idea up earlier, which is how many versions do we support in the past, are we supporting releases for a year or for N releases, if it's just 2 releases does this mean we only support things for 2 months? 19:02:13 #info abhijitkumbhare asks how OpenStack does this, vishnoianil and colindixon say they have shorter project dependency chains and their APIs are more stable/ossified so they have fewer issues with integration 19:02:31 #Info abhijitkumbhare also asks how we fail out if this if it turns out to have been a bad idea 19:03:23 #info vishnoianil points out deprecation and removal will be faster if we keep it the same which could be worse for users since they'd have to worry about changes every 4 months instead of every 6-12 in the past 19:04:25 #info edwarnicke says that we can lead by example by showing how to use integration branches 19:04:51 #info colindixon says that's part of it, wall-clock times being shortened down by a factor of 3 still matters 19:05:41 +1 vishnoianil rovarga LuisGomez 19:06:26 #topic next steps 19:06:38 #info colindixon will start a thread on the mailing list 19:06:49 #info we could delay boron start to get it right and start it this way 19:07:15 #info we could try to do a shadow version of this alongside a more "normal" boron release 19:08:32 My thought: if we (most projects) understand after going thru one more level detail & agree - we can go for it for boron (we don’t necessarily need to wait) 19:09:23 #info edwarnicke proposes other ideas which is that we could have just kernel projects try to opt in for boron and what that mgiht mean 19:09:26 #endmeeting