17:00:29 <phrobb> #startmeeting tsc
17:00:29 <odl_meetbot> Meeting started Thu Jul  9 17:00:29 2015 UTC.  The chair is phrobb. Information about MeetBot at http://ci.openstack.org/meetbot.html.
17:00:29 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:29 <odl_meetbot> The meeting name has been set to 'tsc'
17:00:55 <phrobb> #chair colindixon tbachman
17:00:55 <odl_meetbot> Current chairs: colindixon phrobb tbachman
17:01:03 <colindixon> #topic roll call and agenda bashing
17:01:11 <colindixon> #link https://wiki.opendaylight.org/index.php?title=TSC:Main&oldid=33438#Agenda this week’s agenda frozen in time
17:01:14 * tbachman runs into the room
17:01:14 <regXboi> #info regXboi for edwarnicke
17:01:21 <colindixon> #link 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
17:01:22 <phrobb> #chair regXboi dfarrell07 gzhao
17:01:22 <odl_meetbot> Current chairs: colindixon dfarrell07 gzhao phrobb regXboi tbachman
17:01:23 <colindixon> #info colindixon
17:01:29 <regXboi> #chair tbachman
17:01:29 <odl_meetbot> Current chairs: colindixon dfarrell07 gzhao phrobb regXboi tbachman
17:01:35 <colindixon> #action colindixon to try to find somebody to help with documenting the general procedure for the platform upgrade from Helium to Lithium (for SR1)
17:01:46 <dfarrell07> #info dfarrell07 for Red Hat/cdub
17:01:47 <colindixon> #action ChrisPriceAB to work with rovarga, jmedved, et. al. to look into leveraging OPNFV infrastructure for performance measurements and
17:01:59 <colindixon> #action phrobb to investigate what it takes to get to the license for JIRA, and what the licence would be for
17:02:24 <tbachman> colindixon: I don’t believe he did
17:02:31 <dlenrow> #info dlenrow
17:02:42 <tbachman> there was an email a long while back on these, I think
17:03:03 * tbachman is just catching up after 2week PTO :o
17:03:07 <dfarrell07> #info Nothing happening wrt Jira reports phrobb, Phil reports prio bump and will look at it more this week
17:03:15 <colindixon> #action colindixon and dfarrell07 to talk about automating notifiying projects of test failures
17:03:21 <mohnish> #info mohnish anumala
17:03:25 <colindixon> #action #action colindixon check if gzhao sent out exact cutoff dates/times for Lithium SRs and get him to if he hasn’t
17:03:35 <tbachman> double-action jackson ;)
17:03:42 <colindixon> #action colindixon to send mail asking somebody to represent Martin Sunal’s case as a committer on SXP at a future TSC call
17:03:44 <tbachman> colindixon: I don’t think martin-sunal is here today
17:03:59 <LuisGomez> #info LuisGomez
17:04:06 <abhijitkumbhare> #info abhijitkumbhare (stand-in for ChrisPriceAB )
17:04:11 <tbachman> 5?
17:04:13 <tbachman> 6?
17:04:37 * ebrjohn waiting for him to call Bueler...
17:04:41 <tbachman> #topic Events
17:04:56 <colindixon> #link www.opendaylight.org/news/events/ the usual events page
17:05:06 <tbachman> #info phrobb says it’s time to get dialog going for discussion topics at the ODL Summit’s Design forum
17:05:10 <colindixon> tbachman: thanks!
17:05:23 <colindixon> #info we need topic title, description and a person to lead the topic
17:05:24 <tbachman> #info phrobb is looking for topic titles, brief description, and someone to lead the topic
17:05:26 <tbachman> #undo
17:05:26 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x1bacf10>
17:05:30 <tbachman> colindixon: thx
17:06:05 <colindixon> #info  IETF 93 ODL & SFC Hackathon July 18-19. Contact Charles Eckel (eckelcu@cisco.com) for more information
17:06:23 <tbachman> colindixon: saved tbachman from typing someone’s name incorrectly ;)
17:06:39 <tbachman> #info LuisGomez asked the difference between the design forums and the unconferences
17:06:51 <tbachman> #info phrobb said there will be unconferences as well and will have space for those
17:08:13 <tbachman> #topic stable/lithium and stable/helium updates
17:08:45 <colindixon> #link 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
17:09:27 <colindixon> #link https://lists.opendaylight.org/pipermail/release/2015-July/003076.html asking if projects need more time for Helium-SR4
17:09:50 <colindixon> #info the current cutoff would be 9/12 at 11:59p UTC (which is sunday)
17:11:07 <colindixon> #link https://git.opendaylight.org/gerrit/#/q/project:yangtools+branch:stable/helium yangtools looks like even fewer patches have been merged :-(
17:11:30 <tbachman> #info colindixon asks if folks think that the 9/12 date still makes sense
17:11:35 <colindixon> #info 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
17:12:07 <tbachman> #info colindixon recommends that we push stable/helium SR4 back by at least a week, given the lack of cherry-picks
17:12:19 <dfarrell07> +1 colindixon
17:12:36 <colindixon> #agreed we will push back the Helium-SR4 by (at least) a week to try to get more patches into the release
17:12:47 <colindixon> #action phrobb and gzhao to beat the bushes to try to get cherry-picks out
17:13:25 <tbachman> #info LuisGomez asks how long we need to support the stable/helium branch
17:13:44 <tbachman> #info colindixon says we agreed to support it through the shipping of SR4, but we haven’t agreed what happens beyond that
17:14:10 <colindixon> #action colindixon to start a thread on how long to support stable/helium (also discuss the previous vote)
17:14:29 <tbachman> #topic System Integration and Testing
17:14:48 <colindixon> #undo
17:14:48 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Topic object at 0x1c1ac90>
17:14:54 <colindixon> #topic Infrastructure
17:14:55 <jmedved> #info jmedved
17:14:58 <tbachman> thx colindixon
17:15:18 <colindixon> #Info tykeal_away’s not here (on vacation for two weeks)
17:15:38 <colindixon> #info zxiiro cleaned things up where some slaves were in a “pending to delete” stage, things seem to be running well now
17:15:59 <tbachman> #info LuisGomez asks when the new support person (in Australia) is going become available
17:16:20 <tbachman> #info 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
17:16:59 <tbachman> #info phrobb says people shoudl use the escalation process/chain now, even though the new resource isn’t fully up to speed
17:17:05 <tbachman> shoudl
17:17:06 <tbachman> lol
17:17:09 <colindixon> #info we sent out the escalation process already (to PTLs and only PTLs) because it does actually give you the power to wake people up
17:18:22 <colindixon> #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
17:18:55 <tbachman> #info regXboi says assuming projects elect new PTLs, then we run into the situation where ex-PTLs have this information/power
17:19:22 <tbachman> #info colindixon says that if we end up having problems with this then we can address this then
17:21:30 <colindixon> #info 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).
17:21:44 <tbachman> #topic Beryllium Planning/Board Requests
17:22:09 <colindixon> #link https://wiki.opendaylight.org/view/Simultaneous_Release:Beryllium_Release_Plan the draft release plan
17:22:29 <colindixon> #link https://wiki.opendaylight.org/view/Simultaneous_Release:Beryllium_Release_Plan#Milestone_Readout_Templates we’ve added actual templates for milestone readouts
17:22:41 * tbachman heard “redoubts” ;)
17:23:46 <tbachman> #info colindixon says that each milestone now requires projects to state missing/incomplete things (e.g. if carried over from previous milestones)
17:24:30 <tbachman> #info regXboi says he has issues with the 75% number, as he feels it doesn’t have any meaning
17:25:02 <tbachman> #info 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
17:25:48 <tbachman> #info regXboi says that by writing this requirement, you’re specifying that the projects should be structured in a certain way
17:26:39 <tbachman> #info 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
17:27:01 <tbachman> #info ttkacik says that sonar reports the code coverage from the unit and integration tests that are from the same maven module
17:27:26 <tbachman> #info ttkacik says the jacoco reports which measures the code coverage across all the reports, it looks different
17:27:48 <tbachman> #info colindixon asks if you can pull out code coverage from jacoco reports more easily than sonar
17:28:07 <tbachman> #info ttkacik says jacoco reports are used by sonar
17:28:35 <colindixon> #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
17:29:21 * 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.
17:29:37 <tbachman> #info 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.
17:30:06 <tbachman> #info regXboi is concerned about this requirement driving projects just to meet this requirement, rather than driving “better testing”
17:30:07 <colindixon> #info 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
17:30:33 <tbachman> #info zxiiro says that sonar takes the code coverage from jacoco and runs its own calculations on it, which is why they’re different
17:30:39 * regXboi notes tbachman has cleaned up his words :)
17:30:42 <tbachman> lol
17:30:50 * tbachman hopes he captured the “intent” ;)
17:32:52 <abhijitkumbhare> tbachman: I think this 75% number is not actually “intent” - but how to deliver the “intent” of “better testing”
17:33:01 <tbachman> abhijitkumbhare: ack
17:33:20 * tbachman missed that
17:33:51 <colindixon> #info 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?
17:34:10 <abhijitkumbhare> +1 to the 3 questions colindixon
17:34:10 <colindixon> #info regXboi suggests that he’d like to use the minimum of JaCoCo and sonar for code coverage
17:34:35 <tbachman> regXboi: a cynic?
17:34:41 <tbachman> :|
17:34:59 <phrobb> #info regXboi also notes he is cynical that people will game the system if they get the chance
17:35:08 <tbachman> phrobb: thx
17:36:11 <colindixon> #info regXboi asks if we’ve resolved the version bumping and branch cutting isses, colindixon says no
17:36:23 <tbachman> #info LuisGomez says he doesn’t like the way offsets and branching was handled in Lithium, and would like to have a solution for Beryllium
17:36:26 <abhijitkumbhare> I believe regXboi has it on the money (about folks gaming the system) - but I myself am not sure what is the right approach here (to avoid it becoming an artificial requirement people game the system around)
17:38:12 <tbachman> #info 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)
17:38:28 <mohnish> regXboi/abhijit: Wouldn't it be the PTL's job to avoid this gaming?
17:39:00 <abhijitkumbhare> I am afraid mohnish - that it would be the PTLs who would do the gaming :(
17:39:26 <mohnish> :-)
17:39:57 <regXboi> abhijitkumbhare: +1
17:40:16 * regXboi misquotes "with great power comes the ability to create much havoc"
17:40:55 <abhijitkumbhare> +1 colindixon :)
17:42:02 <phrobb> The 3 choices == decide in the future, all-bump at Offset-0 M5 or Offset-2 M5
17:42:26 <tbachman> #info 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
17:43:29 <colindixon> #info 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
17:44:07 * tbachman channels inner edwarnicke “integration is hard, yo"
17:44:19 <colindixon> #info it seems like there is consensus to do branch cutting and version bumping at the same time to avoid issues
17:44:51 <dfarrell07> Having interacted with a bunch of projects (big and small) via Integration, I'm skeptical that many of them can cherry-pick correctly for a long period
17:45:32 <colindixon> #info 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
17:45:37 <tbachman> #info regXboi notes that offset 0 projects suffer a halt of 4/5 weeks of calendar time
17:48:04 <colindixon> #action tony to send out an e-mail explaining his alternative solution to version bumping and branch cutting
17:48:52 <dfarrell07> +1 colindixon, yes okay with that for now
17:48:59 <tbachman> #info colindixon says that for now, projects are required to version bump some time between offset 0 and offset 2 of M5 milestone
17:49:07 <tbachman> #undo
17:49:07 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x1939490>
17:49:54 <colindixon> #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 M3
17:50:00 <colindixon> #undo
17:50:00 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Agreed object at 0x1939490>
17:50:07 <colindixon> #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
17:50:22 <regXboi> +1
17:50:27 <abhijitkumbhare> regXboi: 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. But yes - this would be a bit painful :(
17:50:39 <dfarrell07> +1
17:50:44 <regXboi> abhijitkumbhare: yes
17:51:05 <tbachman> #info 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.
17:51:30 <odl-casey> colindixon: After the meeting, can I have 2 minutes?
17:51:45 <regXboi> somebody #action me with that so I don't forget again :)
17:51:58 <tbachman> #action regXboi to send out email on continuous release process
17:52:10 <colindixon> #action colindixon to resolve the scope change issue on the mailing list
17:52:17 * regXboi hopes to now remember to remember :)
17:52:24 <tbachman> regXboi: LOL
17:53:09 <dfarrell07> +1 to docs committers vote
17:53:14 <tbachman> #info 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
17:54:00 <tbachman> #info ttkacik  notes that to make the feature stable, you’re putting the power in the hands of another project (i.e. docs project committers)
17:55:17 <tbachman> #info 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)
17:56:06 <colindixon> #action colindixon to remove the TODO about scope changes, because it is and wil be resolved by the TSC
17:57:13 <mohnish> Luis: +1
17:57:21 <colindixon> #action colindixon to remove the TODO about what adequate docuementation should be defined as
17:57:34 <phrobb> #info 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.
17:57:43 <colindixon> #action colindixon to add a note that the TSC must vote on whether ot not each stable feature has met the requirements
17:57:44 <tbachman> phrobb: thx
17:58:41 <colindixon> #info 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
17:58:46 <dfarrell07> I hope that we end up asking the docs committers if the docs are actually good (vs us rubber stamping it), but I'm fine with the vote being owned by the TSC. I think this is what LuisGomez was saying.
17:59:08 <dfarrell07> colindixon: +1
17:59:27 <tbachman> #info colindixon asks if we have something we can articulate as a requirement for security features
17:59:58 <tbachman> #undo
17:59:58 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x19d7ad0>
18:00:05 <tbachman> #info colindixon asks if we have something we can articulate as a requirement for security requirements
18:00:14 <tbachman> lol
18:00:16 <tbachman> 3rd try
18:00:17 <tbachman> #undo
18:00:17 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x1834ed0>
18:00:33 <tbachman> #info colindixon asks if we have something we can articulate as a requirement for security
18:00:45 <abhijitkumbhare> I think we should consider using industry standard terms like alpha, beta & release candidate for the features (instead of the terms experimental, ready and stable)
18:01:09 <tbachman> #info 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
18:01:51 <dfarrell07> regXboi: +1
18:02:33 <colindixon> #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
18:02:51 <colindixon> #action colindixon to make the above changes and send out a mail asking for a vote this week
18:03:28 <mohnish> colin: not fixable - may be subjective interpretation and work involved to get around
18:03:55 <colindixon> mohnish: maybe the TSC should have to vote to allow an exceptoin
18:04:29 <dfarrell07> Thanks @ all :)_
18:04:38 <colindixon> #info mohnish asks if we should make “not fixable” in terms of security less ambigous
18:04:41 <regXboi> #topic cookies :)
18:04:44 <colindixon> #undo
18:04:44 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Topic object at 0x1ce03d0>
18:04:46 <colindixon> hold on :p
18:04:50 <dfarrell07> lol
18:04:58 <tbachman> lol
18:04:59 <tbachman> regXboi: chucked your cookies ;)
18:05:16 <colindixon> #info 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
18:05:19 <colindixon> #topic cookies
18:05:19 <regXboi> colindixon doesn't like my cookies :)
18:05:22 <colindixon> #endmeeting