18:00:54 <phrobb> #startmeeting tws
18:00:54 <odl_meetbot> Meeting started Mon Feb  8 18:00:54 2016 UTC.  The chair is phrobb. Information about MeetBot at http://ci.openstack.org/meetbot.html.
18:00:54 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:54 <odl_meetbot> The meeting name has been set to 'tws'
18:02:40 <phrobb> #topic Today's meeting is on Boron Planning
18:03:27 <phrobb> #chair anipbu CaseyODL colindixon
18:03:27 <odl_meetbot> Current chairs: CaseyODL anipbu colindixon phrobb
18:03:49 <colindixon> thanks
18:06:10 <edwarnicke> Also people other than edwarnicke ;)
18:08:08 <colindixon> #info colindixon says at this point we need to decide (soon) whether we want to do a more normal Boron release and look at fast-phased in Carbon, or try to do it in Boron
18:08:59 <colindixon> #info skitt says that his take is that should be mostly up to offset 0 proejcts
18:10:00 <colindixon> #info colindixon notes that we don't really have any of them
18:10:16 <colindixon> #Info vishnoianil asks if we have a good writeup of pros and cons of the two approaches
18:12:19 <colindixon> #info colindixon says he doesn't think they're writtne down concretely except in minutes
18:13:53 <phrobb> #info Anil asks if there is a detailed write up of rational for the change and new issues expected as a result of such a change.  colindixon  notes that there isn't really document with this information... the general rational for the change is a move to agile, faster releases so that projects have less time to get into trouble related to integration/dependency issues.  Also, the method is trying to more loosely couple
18:13:54 <phrobb> the upstream/downstream projects and their dependent versions to avoid such breakages.
18:14:03 <colindixon> #info colindixon says he thinks there are two key independent pros: (1) shorter releases are easier to manage in general, (2) corss-offset dependencies would be on released versions helping to avoid transient breakages
18:14:54 <colindixon> #info edwarnicke notes that there's a thrid: integrating with external projects (in both directlions) has to wait less time if you can release more often, e.g., don't have to wait up to 6 months to integrate
18:15:43 * zxiiro likes the model as well. Smaller autoreleases means we don't have to wait 12 hrs for a build.
18:17:34 <colindixon> #info colindixon says the biggest cons seem to be (1) a potential explosion of branches, (2) you have to wait until upstream projects release to get bug fixes, (2) unknown unknowns
18:18:28 <colindixon> #info edwarnicke says that one way you can avoid an explosion of branches is to not have all releases be long-term-support, colindixon notes that we talked about this last time
18:19:19 <colindixon> #Info edwarnicke asks if he could prepare a parameterzied proposal, many people say sure but would like to see a spreadsheet they can tweak and at least one concrete example
18:20:41 <colindixon> #info skitt says that a lot of this complexity comes down how long releases are supported to external customers and how fast downstream projects are willing to move to newer releases
18:23:03 <colindixon> #info skitt also notes that semantic versioning might help to make sure projects were willing to do some upgrades (e.g., safe ones) more often
18:24:56 * edwarnicke mourns that doing every third release as LTS means we skip Ne (a Nobel Gas) as LTS :(
18:25:10 * edwarnicke really wanted to do another Noble Gas Release
18:25:10 <colindixon> #info vishnoianil asks the obvious question of whether there is too much overhead in a 2 month release
18:25:30 <colindixon> #info edwarnicke says yes, it's possible, other things get easier because you're coordinating with fewer other projects
18:25:32 <zxiiro> Does that mean for non LTS release we won't have a stable/branch for them?
18:25:57 <edwarnicke> zxiiro: Not clear yet, but the notion would be no a *long term* stable/branch
18:25:58 <colindixon> zxiiro: my guess you would but only one non-LTS stable brnach
18:26:40 <colindixon> so, you coudl fix bugs in the most recent non-LTS, but not have to keep more than one
18:28:43 <colindixon> #info another key con you potentially have to deal with is version skew
18:29:25 <colindixon> #action edwarnicke to write up a list of pros/cons and maybe a parameterized list of this plan
18:30:34 <colindixon> #info skitt talks about how you might manage overhead by not delivering new functionaliy every release, e.g., only shipping new functionality only when it's ready, you can do this with topic branches or unpublished karaf features or other ways
18:32:37 <colindixon> #info vishnoianil notes that there is risk with putting features that might not be completed, then you're sort of stuck with half done things
18:33:07 <colindixon> #info edwarnicke points out (and colindixon and vishnoianil mostly agree) that topic branches have their own issues
18:35:20 <zxiiro> Maven sites is able to generate reports too. See: https://nexus.opendaylight.org/content/sites/site/org.opendaylight.yangtools/boron/dependency-convergence.html
18:35:48 <colindixon> #info skitt notes that to handle version skew we need new tooling, and then likely a carrot and stick approach to getting projects to upgrade to new versions
18:36:44 <colindixon> #info skitt notes that might be new functionality (carrot) and lack of support (stick) and maybe mandatory version (ranges) to be part of an "OpenDaylight" release vs. a project release
18:41:14 <colindixon> #info skitt and colindixon talk about the complexities of trying to deal with version ranges
18:41:55 <colindixon> #info skitt notes that there's source-code level compatibility that won't necessarily guarantee binary compatibility for things like yantools version they were released with
18:44:05 <colindixon> #info LuisGomez says that depending on multiple different releases makes testing harder (which it does) and mabye we should just make everyone use the latest LTS when we release it
18:45:10 <colindixon> #info skitt notes that we need to define what it means to be part of the ODL community and his hope would be that if something critical is in need of help, then they would get the help they asked for
18:51:50 <colindixon> #info anipbu asks if projects can choose to skip a simultaneous release. colindixon says as our governance is written projects are allowed to participate or not as they see fit
18:52:26 <colindixon> #Info colindixon says he really hopes that we make participating in a release simple enough that people don't worry about choosing to opt-in
18:54:42 <colindixon> #info colindixon notes that his experience is that the time somebody says "I won't participate in this one, I'll do the next one" is often the last time they make progress becaue it gets harder to integrate
18:55:57 <colindixon> #info anipbu asks about how SRs would work, would we still have them
18:58:24 <colindixon> #info colindixon says he thinks we'd need to so that we could fix bugs for downstream projects in betwen releases, and they might be more often beaause there won't be as much direct integration testing without snapshot integration
18:59:18 <colindixon> #info skitt noted way up above that upgrading versions is really complicated here because we have at least 4 versions: yang revisions, osgi versions, maven versions, and karaf feature versions
19:01:14 <colindixon> #topic next teps
19:01:20 <colindixon> #undo
19:01:20 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Topic object at 0x203ce90>
19:01:31 <colindixon> #topic next steps
19:01:49 <colindixon> #info the next steps seem to be (1) writing this up and (2) figuring out if offset 0/kernel projects want to do it for boron
19:01:54 <colindixon> #endmeeting