#opendaylight-meeting: tws

Meeting started by phrobb at 18:00:54 UTC (full logs).

Meeting summary

  1. Today's meeting is on Boron Planning (phrobb, 18:02:40)
    1. 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 (colindixon, 18:08:08)
    2. skitt says that his take is that should be mostly up to offset 0 proejcts (colindixon, 18:08:59)
    3. colindixon notes that we don't really have any of them (colindixon, 18:10:00)
    4. vishnoianil asks if we have a good writeup of pros and cons of the two approaches (colindixon, 18:10:16)
    5. colindixon says he doesn't think they're writtne down concretely except in minutes (colindixon, 18:12:19)
    6. 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 (phrobb, 18:13:53)
    7. 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 (colindixon, 18:14:03)
    8. 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 (colindixon, 18:14:54)
    9. 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 (colindixon, 18:17:34)
    10. 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 (colindixon, 18:18:28)
    11. 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 (colindixon, 18:19:19)
    12. 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 (colindixon, 18:20:41)
    13. skitt also notes that semantic versioning might help to make sure projects were willing to do some upgrades (e.g., safe ones) more often (colindixon, 18:23:03)
    14. vishnoianil asks the obvious question of whether there is too much overhead in a 2 month release (colindixon, 18:25:10)
    15. edwarnicke says yes, it's possible, other things get easier because you're coordinating with fewer other projects (colindixon, 18:25:30)
    16. another key con you potentially have to deal with is version skew (colindixon, 18:28:43)
    17. ACTION: edwarnicke to write up a list of pros/cons and maybe a parameterized list of this plan (colindixon, 18:29:25)
    18. 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 (colindixon, 18:30:34)
    19. vishnoianil notes that there is risk with putting features that might not be completed, then you're sort of stuck with half done things (colindixon, 18:32:37)
    20. edwarnicke points out (and colindixon and vishnoianil mostly agree) that topic branches have their own issues (colindixon, 18:33:07)
    21. 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 (colindixon, 18:35:48)
    22. 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 (colindixon, 18:36:44)
    23. skitt and colindixon talk about the complexities of trying to deal with version ranges (colindixon, 18:41:14)
    24. 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 (colindixon, 18:41:55)
    25. 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 (colindixon, 18:44:05)
    26. 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 (colindixon, 18:45:10)
    27. 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 (colindixon, 18:51:50)
    28. colindixon says he really hopes that we make participating in a release simple enough that people don't worry about choosing to opt-in (colindixon, 18:52:26)
    29. 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 (colindixon, 18:54:42)
    30. anipbu asks about how SRs would work, would we still have them (colindixon, 18:55:57)
    31. 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 (colindixon, 18:58:24)
    32. 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 (colindixon, 18:59:18)

  2. next steps (colindixon, 19:01:31)
    1. 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 (colindixon, 19:01:49)


Meeting ended at 19:01:54 UTC (full logs).

Action items

  1. edwarnicke to write up a list of pros/cons and maybe a parameterized list of this plan


Action items, by person

  1. edwarnicke
    1. edwarnicke to write up a list of pros/cons and maybe a parameterized list of this plan


People present (lines said)

  1. colindixon (39)
  2. phrobb (5)
  3. odl_meetbot (5)
  4. edwarnicke (4)
  5. zxiiro (3)
  6. anipbu (0)
  7. CaseyODL (0)


Generated by MeetBot 0.1.4.