#opendaylight-meeting: tsc

Meeting summary

1. roll call and agenda bashing (colindixon, 17:01:03)
   1. https://wiki.opendaylight.org/index.php?title=TSC:Main&oldid=33438#Agenda this week’s agenda frozen in time (colindixon, 17:01:11)
   2. regXboi for edwarnicke (regXboi, 17:01:14)
   3. https://meetings.opendaylight.org/opendaylight-meeting/2015/tsc/opendaylight-meeting-tsc.2015-07-02-17.00.html last week’s meeting minutes for action items (colindixon, 17:01:21)
   4. colindixon (colindixon, 17:01:23)
   5. ACTION: colindixon to try to find somebody to help with documenting the general procedure for the platform upgrade from Helium to Lithium (for SR1) (colindixon, 17:01:35)
   6. dfarrell07 for Red Hat/cdub (dfarrell07, 17:01:46)
   7. ACTION: ChrisPriceAB to work with rovarga, jmedved, et. al. to look into leveraging OPNFV infrastructure for performance measurements and (colindixon, 17:01:47)
   8. ACTION: phrobb to investigate what it takes to get to the license for JIRA, and what the licence would be for (colindixon, 17:01:59)
   9. dlenrow (dlenrow, 17:02:31)
   10. Nothing happening wrt Jira reports phrobb, Phil reports prio bump and will look at it more this week (dfarrell07, 17:03:07)
   11. ACTION: colindixon and dfarrell07 to talk about automating notifiying projects of test failures (colindixon, 17:03:15)
   12. mohnish anumala (mohnish, 17:03:21)
   13. ACTION: #action colindixon check if gzhao sent out exact cutoff dates/times for Lithium SRs and get him to if he hasn’t (colindixon, 17:03:25)
   14. ACTION: colindixon to send mail asking somebody to represent Martin Sunal’s case as a committer on SXP at a future TSC call (colindixon, 17:03:42)
   15. LuisGomez (LuisGomez, 17:03:59)
   16. abhijitkumbhare (stand-in for ChrisPriceAB ) (abhijitkumbhare, 17:04:06)
   
   
2. Events (tbachman, 17:04:41)
   1. www.opendaylight.org/news/events/ the usual events page (colindixon, 17:04:56)
   2. phrobb says it’s time to get dialog going for discussion topics at the ODL Summit’s Design forum (tbachman, 17:05:06)
   3. we need topic title, description and a person to lead the topic (colindixon, 17:05:23)
   4. IETF 93 ODL & SFC Hackathon July 18-19. Contact Charles Eckel (eckelcu@cisco.com) for more information (colindixon, 17:06:05)
   5. LuisGomez asked the difference between the design forums and the unconferences (tbachman, 17:06:39)
   6. phrobb said there will be unconferences as well and will have space for those (tbachman, 17:06:51)
   
   
3. stable/lithium and stable/helium updates (tbachman, 17:08:13)
   1. https://git.opendaylight.org/gerrit/#/q/project:controller+branch:stable/helium just to pick one random project that should likely have a bunch of cherry-picks to stable/helium, here’s the controller and it’s pretty light (colindixon, 17:08:45)
   2. https://lists.opendaylight.org/pipermail/release/2015-July/003076.html asking if projects need more time for Helium-SR4 (colindixon, 17:09:27)
   3. the current cutoff would be 9/12 at 11:59p UTC (which is sunday) (colindixon, 17:09:50)
   4. https://git.opendaylight.org/gerrit/#/q/project:yangtools+branch:stable/helium yangtools looks like even fewer patches have been merged :-( (colindixon, 17:11:07)
   5. colindixon asks if folks think that the 9/12 date still makes sense (tbachman, 17:11:30)
   6. colindixon thinks that it looks like we might need more time than 3 days (and one business day) to get things cherry-picked to stable/helium (colindixon, 17:11:35)
   7. colindixon recommends that we push stable/helium SR4 back by at least a week, given the lack of cherry-picks (tbachman, 17:12:07)
   8. AGREED: we will push back the Helium-SR4 by (at least) a week to try to get more patches into the release (colindixon, 17:12:36)
   9. ACTION: phrobb and gzhao to beat the bushes to try to get cherry-picks out (colindixon, 17:12:47)
   10. LuisGomez asks how long we need to support the stable/helium branch (tbachman, 17:13:25)
   11. colindixon says we agreed to support it through the shipping of SR4, but we haven’t agreed what happens beyond that (tbachman, 17:13:44)
   12. ACTION: colindixon to start a thread on how long to support stable/helium (also discuss the previous vote) (colindixon, 17:14:10)
   
   
4. Infrastructure (colindixon, 17:14:54)
   1. jmedved (jmedved, 17:14:55)
   2. tykeal_away’s not here (on vacation for two weeks) (colindixon, 17:15:18)
   3. zxiiro cleaned things up where some slaves were in a “pending to delete” stage, things seem to be running well now (colindixon, 17:15:38)
   4. LuisGomez asks when the new support person (in Australia) is going become available (tbachman, 17:15:59)
   5. phrobb says this person came on board last week; tykeal and zxiiro are going to bring him up to speed in the next few weeks (tbachman, 17:16:20)
   6. phrobb says people shoudl use the escalation process/chain now, even though the new resource isn’t fully up to speed (tbachman, 17:16:59)
   7. we sent out the escalation process already (to PTLs and only PTLs) because it does actually give you the power to wake people up (colindixon, 17:17:09)
   8. ACTION: phrobb to send out mail when the new infra person is up-to-speed so that he knows when he will not be waking people up after hours (colindixon, 17:18:22)
   9. regXboi says assuming projects elect new PTLs, then we run into the situation where ex-PTLs have this information/power (tbachman, 17:18:55)
   10. colindixon says that if we end up having problems with this then we can address this then (tbachman, 17:19:22)
   11. Neelajacques suggests just following the guidelines in the escalations, e.g., if something is causing significant problems then read the guidelines and send out mail. Do not avoid following the guidelines to avoid hurting somebody’s feelings (or sleep). (colindixon, 17:21:30)
   
   
5. Beryllium Planning/Board Requests (tbachman, 17:21:44)
   1. https://wiki.opendaylight.org/view/Simultaneous_Release:Beryllium_Release_Plan the draft release plan (colindixon, 17:22:09)
   2. https://wiki.opendaylight.org/view/Simultaneous_Release:Beryllium_Release_Plan#Milestone_Readout_Templates we’ve added actual templates for milestone readouts (colindixon, 17:22:29)
   3. colindixon says that each milestone now requires projects to state missing/incomplete things (e.g. if carried over from previous milestones) (tbachman, 17:23:46)
   4. regXboi says he has issues with the 75% number, as he feels it doesn’t have any meaning (tbachman, 17:24:30)
   5. colindixon says they’ve asked proejcts that are most likely to move to “stable” in this release, and they thought the 75% number was reasonable (tbachman, 17:25:02)
   6. regXboi says that by writing this requirement, you’re specifying that the projects should be structured in a certain way (tbachman, 17:25:48)
   7. colindixon acknowledges that code coverage is per pom-fle, so if there is a feature that spans more than one pom file, you would have to do a weighted average (tbachman, 17:26:39)
   8. ttkacik says that sonar reports the code coverage from the unit and integration tests that are from the same maven module (tbachman, 17:27:01)
   9. ttkacik says the jacoco reports which measures the code coverage across all the reports, it looks different (tbachman, 17:27:26)
   10. colindixon asks if you can pull out code coverage from jacoco reports more easily than sonar (tbachman, 17:27:48)
   11. ttkacik says jacoco reports are used by sonar (tbachman, 17:28:07)
   12. ACTION: tony and zxiiro to look at the sonar/jacoco reports and try to figure out how (and if) we can reasonby get feature-leverl code coverage information (colindixon, 17:28:35)
   13. phrobb thinks 75% sonar coverage is a reasonable starting point. We allow the TSC to waive a requirement if it doesn't make sense. If they end up having to waive the requirement multiple times, the TSC can adjust that number/requirement at that time.... Assuming the "lessoning of a requirement" mid-release is acceptable to participating projects. (tbachman, 17:29:37)
   14. regXboi is concerned about this requirement driving projects just to meet this requirement, rather than driving “better testing” (tbachman, 17:30:06)
   15. colindixon says that the TSC will obviously waive th code coverage requirement if it turns out to be an impossible question to ask for code coverage of a feature, however it *seems* like it *should* be possilbe (colindixon, 17:30:07)
   16. zxiiro says that sonar takes the code coverage from jacoco and runs its own calculations on it, which is why they’re different (tbachman, 17:30:33)
   17. there are three questions: (1) is it possible to get feature-level code coverage? (2) if it is, do we want to use JaCoCo or sonar? and (3) is 75% a good number? (colindixon, 17:33:51)
   18. regXboi suggests that he’d like to use the minimum of JaCoCo and sonar for code coverage (colindixon, 17:34:10)
   19. regXboi also notes he is cynical that people will game the system if they get the chance (phrobb, 17:34:59)
   20. regXboi asks if we’ve resolved the version bumping and branch cutting isses, colindixon says no (colindixon, 17:36:11)
   21. LuisGomez says he doesn’t like the way offsets and branching was handled in Lithium, and would like to have a solution for Beryllium (tbachman, 17:36:23)
   22. abhijitkumbhare agrees with regXboi about gaming the system, but is not sure what is the right approach here (to avoid it becoming an artificial requirement people game the system around) (tbachman, 17:38:12)
   23. LuisGomez proposed 3 options for cutting stability brannches : 1) do it at M5 for each project (as per Lithium); 2) do all of them at M5 offset 0 or 3) do it all at M5 offset 2 (tbachman, 17:42:26)
   24. tony says that we should wait to pick a date until we are closer to M5 based on how things proress, maybe make sure to have it done by offset 0 M3 (colindixon, 17:43:29)
   25. it seems like there is consensus to do branch cutting and version bumping at the same time to avoid issues (colindixon, 17:44:19)
   26. colindixon and abhijitkumbhare both argue that offset 2 M5 makes the most sense as the projects that have to deal with the most pain (offset 0 and offset 1) are the ones with the most discipline and also fewer in number than offset 2 in general (colindixon, 17:45:32)
   27. regXboi notes that offset 0 projects suffer a halt of 4/5 weeks of calendar time (tbachman, 17:45:37)
   28. ACTION: tony to send out an e-mail explaining his alternative solution to version bumping and branch cutting (colindixon, 17:48:04)
   29. AGREED: we will update the release plan to say that branch cutting will happen sometime between offset 0 M5 and offset 2 M5 (and may or may not staggered), the TSC will commit to set a date by offset 0 M4 (colindixon, 17:50:07)
   30. abhijitkumbhare notes that there would be workarounds to offset 0 and 1 (halt of 4-5 week calendar time for next release) but a little painful - create a development branch the other way for new feature development for the next release & merge back the new features for the new release for master at a later time. (tbachman, 17:51:05)
   31. ACTION: regXboi to send out email on continuous release process (tbachman, 17:51:58)
   32. ACTION: colindixon to resolve the scope change issue on the mailing list (colindixon, 17:52:10)
   33. colindixon says that there’s a requirement that to be a stable feature, the project has to provide adequate documentation for the feature; the problem is the definition of adequate documentation (tbachman, 17:53:14)
   34. ttkacik notes that to make the feature stable, you’re putting the power in the hands of another project (i.e. docs project committers) (tbachman, 17:54:00)
   35. colindixon says this could be changed to have this requirement voted on by the TSC; or, it could be left vague (and left for interpretation by the TSC) (tbachman, 17:55:17)
   36. ACTION: colindixon to remove the TODO about scope changes, because it is and wil be resolved by the TSC (colindixon, 17:56:06)
   37. ACTION: colindixon to remove the TODO about what adequate docuementation should be defined as (colindixon, 17:57:21)
   38. consensus forming around the TSC having the responsibility to determine if adequate documentation has been provided for a stable feature. The TSC may request the input of the Documentation team in part of their evaluation. (phrobb, 17:57:34)
   39. ACTION: colindixon to add a note that the TSC must vote on whether ot not each stable feature has met the requirements (colindixon, 17:57:43)
   40. the TSC descides it hasn’t met the requirements, then it would no loger be stable and all features that depended also thus could no logner be stable (colindixon, 17:58:41)
   41. colindixon asks if we have something we can articulate as a requirement for security (tbachman, 18:00:33)
   42. ttkacik notes that there could be security vulnerabilities in 3rd part libs which are beyond our control, and therefore may not be able to meet certain requirements (tbachman, 18:01:09)
   43. ACTION: colindixon to add information about security vulnerabilities that if it is not fixable in opendaylight code, it shoudln’t be held against the project (colindixon, 18:02:33)
   44. ACTION: colindixon to make the above changes and send out a mail asking for a vote this week (colindixon, 18:02:51)
   45. mohnish asks if we should make “not fixable” in terms of security less ambigous (colindixon, 18:04:38)
   46. colindixon says maybe saying it can be waived by vote of the TSC is better, colindixon also notes that the TSC has the right to waive any stable feautre requirement (colindixon, 18:05:16)
   
   
6. cookies (colindixon, 18:05:19)

Action items

1. colindixon to try to find somebody to help with documenting the general procedure for the platform upgrade from Helium to Lithium (for SR1)
2. ChrisPriceAB to work with rovarga, jmedved, et. al. to look into leveraging OPNFV infrastructure for performance measurements and
3. phrobb to investigate what it takes to get to the license for JIRA, and what the licence would be for
4. colindixon and dfarrell07 to talk about automating notifiying projects of test failures
5. #action colindixon check if gzhao sent out exact cutoff dates/times for Lithium SRs and get him to if he hasn’t
6. colindixon to send mail asking somebody to represent Martin Sunal’s case as a committer on SXP at a future TSC call
7. phrobb and gzhao to beat the bushes to try to get cherry-picks out
8. colindixon to start a thread on how long to support stable/helium (also discuss the previous vote)
9. phrobb to send out mail when the new infra person is up-to-speed so that he knows when he will not be waking people up after hours
10. tony and zxiiro to look at the sonar/jacoco reports and try to figure out how (and if) we can reasonby get feature-leverl code coverage information
11. tony to send out an e-mail explaining his alternative solution to version bumping and branch cutting
12. regXboi to send out email on continuous release process
13. colindixon to resolve the scope change issue on the mailing list
14. colindixon to remove the TODO about scope changes, because it is and wil be resolved by the TSC
15. colindixon to remove the TODO about what adequate docuementation should be defined as
16. colindixon to add a note that the TSC must vote on whether ot not each stable feature has met the requirements
17. colindixon to add information about security vulnerabilities that if it is not fixable in opendaylight code, it shoudln’t be held against the project
18. colindixon to make the above changes and send out a mail asking for a vote this week

Action items, by person

1. colindixon
   1. colindixon to try to find somebody to help with documenting the general procedure for the platform upgrade from Helium to Lithium (for SR1)
   2. colindixon and dfarrell07 to talk about automating notifiying projects of test failures
   3. #action colindixon check if gzhao sent out exact cutoff dates/times for Lithium SRs and get him to if he hasn’t
   4. colindixon to send mail asking somebody to represent Martin Sunal’s case as a committer on SXP at a future TSC call
   5. colindixon to start a thread on how long to support stable/helium (also discuss the previous vote)
   6. colindixon to resolve the scope change issue on the mailing list
   7. colindixon to remove the TODO about scope changes, because it is and wil be resolved by the TSC
   8. colindixon to remove the TODO about what adequate docuementation should be defined as
   9. colindixon to add a note that the TSC must vote on whether ot not each stable feature has met the requirements
   10. colindixon to add information about security vulnerabilities that if it is not fixable in opendaylight code, it shoudln’t be held against the project
   11. colindixon to make the above changes and send out a mail asking for a vote this week
2. dfarrell07
   1. colindixon and dfarrell07 to talk about automating notifiying projects of test failures
3. gzhao
   1. #action colindixon check if gzhao sent out exact cutoff dates/times for Lithium SRs and get him to if he hasn’t
   2. phrobb and gzhao to beat the bushes to try to get cherry-picks out
4. jmedved
   1. ChrisPriceAB to work with rovarga, jmedved, et. al. to look into leveraging OPNFV infrastructure for performance measurements and
5. phrobb
   1. phrobb to investigate what it takes to get to the license for JIRA, and what the licence would be for
   2. phrobb and gzhao to beat the bushes to try to get cherry-picks out
   3. phrobb to send out mail when the new infra person is up-to-speed so that he knows when he will not be waking people up after hours
6. regXboi
   1. regXboi to send out email on continuous release process
7. UNASSIGNED
   1. tony and zxiiro to look at the sonar/jacoco reports and try to figure out how (and if) we can reasonby get feature-leverl code coverage information
   2. tony to send out an e-mail explaining his alternative solution to version bumping and branch cutting

People present (lines said)

1. tbachman (75)
2. colindixon (57)
3. odl_meetbot (13)
4. dfarrell07 (12)
5. regXboi (11)
6. abhijitkumbhare (8)
7. phrobb (7)
8. mohnish (5)
9. ebrjohn (1)
10. dlenrow (1)
11. jmedved (1)
12. LuisGomez (1)
13. odl-casey (1)
14. gzhao (0)