18:02:56 <colindixon> #startmeeting tws
18:02:56 <odl_meetbot> 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 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:56 <odl_meetbot> The meeting name has been set to 'tws'
18:03:01 <colindixon> #topic agenda bashing
18:04:31 <colindixon> #link https://wiki.opendaylight.org/index.php?title=Tech_Work_Stream:Main&oldid=40524#Upcoming_Meeting_Agendas the agenda for today
18:06:02 <colindixon> #info today we'll cover boron planning
18:06:25 <colindixon> #info two topics: (i) fast-phased approach for shorter releases and (ii) advisory group input on boron
18:07:09 <colindixon> #topic advisory group input for Boron
18:07:36 <colindixon> #link https://lists.opendaylight.org/pipermail/tsc/2016-January/004565.html
18:15:27 <colindixon> #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 <colindixon> #info examples of (1) are things like BGP add-path and/or aggregated logs/alrsm
18:17:50 <colindixon> #Info examples of (2) are things like [easier] upgrades between releases
18:22:02 <colindixon> #info (3) is stuff like better defining the role of ODL as  VNF manager vs. controller vs. NFV orchestrator
18:22:11 <colindixon> #topic easier upgrades
18:22:52 <colindixon> #info easier upgrades were something that was the top prioirty coming out of the advisory group
18:26:48 <colindixon> #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 <colindixon> #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 <edwarnicke> #link https://docs.google.com/presentation/d/1IKI8DV3oqb1snJLCaK6lLvvCXCnpEolQ6Xp_Qlk6E8M/edit
18:29:55 <colindixon> #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 <colindixon> #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 <colindixon> #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 <colindixon> #info uri worries faster releases will potentially signal instability
18:35:31 <colindixon> #info edwarnicke presents his fast-phased approch with the diagram about the different branches
18:35:40 <colindixon> #Undo
18:35:40 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x1f702d0>
18:35:53 <colindixon> #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 <colindixon> #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 <colindixon> #Info edwarnicke says it's all trade-offs, colindixon agrees
18:38:40 <colindixon> #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 <colindixon> #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 <colindixon> #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 <colindixon> #info edwarnicke says there's only so much trouble developers can get in in 2 months
18:44:38 <colindixon> #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 <colindixon> #topic planning how fast-phased would work
18:49:43 <colindixon> #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 <colindixon> #info colindixon ask kernel project devs how crazy this looks to them
18:51:17 <colindixon> #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 <colindixon> #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 <colindixon> #info rovarga also says that this needs to be fleshed out a lot more before we can commit to it
18:54:35 <colindixon> #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 <colindixon> #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 <colindixon> #info skitt, rovarga and others argue that we should abandon text-named versions, e.g., -Lithium or -Lithium-SR1, etc.
18:59:19 <colindixon> #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 <colindixon> #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 <colindixon> #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 <colindixon> #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 <colindixon> #Info abhijitkumbhare also asks how we fail out if this if it turns out to have been a bad idea
19:03:23 <colindixon> #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 <colindixon> #info edwarnicke says that we can lead by example by showing how to use integration branches
19:04:51 <colindixon> #info colindixon says that's part of it, wall-clock times being shortened down by a factor of 3 still matters
19:05:41 <abhijitkumbhare> +1 vishnoianil rovarga LuisGomez
19:06:26 <colindixon> #topic next steps
19:06:38 <colindixon> #info colindixon will start a thread on the mailing list
19:06:49 <colindixon> #info we could delay boron start to get it right and start it this way
19:07:15 <colindixon> #info we could try to do a shadow version of this alongside a more "normal" boron release
19:08:32 <abhijitkumbhare> 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 <colindixon> #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 <colindixon> #endmeeting