#opendaylight-meeting: tsc
Meeting started by phrobb at 17:00:29 UTC
(full logs).
Meeting summary
- roll call and agenda bashing (colindixon, 17:01:03)
- https://wiki.opendaylight.org/index.php?title=TSC:Main&oldid=33438#Agenda
this week’s agenda frozen in time (colindixon,
17:01:11)
- regXboi for edwarnicke (regXboi,
17:01:14)
- 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)
- colindixon (colindixon,
17:01:23)
- 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)
- dfarrell07 for Red Hat/cdub (dfarrell07,
17:01:46)
- ACTION: ChrisPriceAB
to work with rovarga, jmedved, et. al. to look into leveraging OPNFV
infrastructure for performance measurements and (colindixon,
17:01:47)
- 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)
- dlenrow (dlenrow,
17:02:31)
- Nothing happening wrt Jira reports phrobb, Phil
reports prio bump and will look at it more this week (dfarrell07,
17:03:07)
- ACTION: colindixon
and dfarrell07 to talk about automating notifiying projects of test
failures (colindixon,
17:03:15)
- mohnish anumala (mohnish,
17:03:21)
- 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)
- 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)
- LuisGomez (LuisGomez,
17:03:59)
- abhijitkumbhare (stand-in for ChrisPriceAB
) (abhijitkumbhare,
17:04:06)
- Events (tbachman, 17:04:41)
- www.opendaylight.org/news/events/
the usual events page (colindixon,
17:04:56)
- phrobb says it’s time to get dialog going for
discussion topics at the ODL Summit’s Design forum (tbachman,
17:05:06)
- we need topic title, description and a person
to lead the topic (colindixon,
17:05:23)
- IETF 93 ODL & SFC Hackathon July 18-19.
Contact Charles Eckel (eckelcu@cisco.com) for more
information (colindixon,
17:06:05)
- LuisGomez asked the difference between the
design forums and the unconferences (tbachman,
17:06:39)
- phrobb said there will be unconferences as well
and will have space for those (tbachman,
17:06:51)
- stable/lithium and stable/helium updates (tbachman, 17:08:13)
- 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)
- https://lists.opendaylight.org/pipermail/release/2015-July/003076.html
asking if projects need more time for Helium-SR4 (colindixon,
17:09:27)
- the current cutoff would be 9/12 at 11:59p UTC
(which is sunday) (colindixon,
17:09:50)
- https://git.opendaylight.org/gerrit/#/q/project:yangtools+branch:stable/helium
yangtools looks like even fewer patches have been merged :-( (colindixon,
17:11:07)
- colindixon asks if folks think that the 9/12
date still makes sense (tbachman,
17:11:30)
- 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)
- colindixon recommends that we push
stable/helium SR4 back by at least a week, given the lack of
cherry-picks (tbachman,
17:12:07)
- 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)
- ACTION: phrobb and
gzhao to beat the bushes to try to get cherry-picks out (colindixon,
17:12:47)
- LuisGomez asks how long we need to support the
stable/helium branch (tbachman,
17:13:25)
- 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)
- ACTION: colindixon to
start a thread on how long to support stable/helium (also discuss
the previous vote) (colindixon,
17:14:10)
- Infrastructure (colindixon, 17:14:54)
- jmedved (jmedved,
17:14:55)
- tykeal_away’s not here (on vacation for two
weeks) (colindixon,
17:15:18)
- 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)
- LuisGomez asks when the new support person (in
Australia) is going become available (tbachman,
17:15:59)
- 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)
- 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)
- 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)
- 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)
- regXboi says assuming projects elect new PTLs,
then we run into the situation where ex-PTLs have this
information/power (tbachman,
17:18:55)
- colindixon says that if we end up having
problems with this then we can address this then (tbachman,
17:19:22)
- 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)
- Beryllium Planning/Board Requests (tbachman, 17:21:44)
- https://wiki.opendaylight.org/view/Simultaneous_Release:Beryllium_Release_Plan
the draft release plan (colindixon,
17:22:09)
- 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)
- 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)
- regXboi says he has issues with the 75% number,
as he feels it doesn’t have any meaning (tbachman,
17:24:30)
- 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)
- regXboi says that by writing this requirement,
you’re specifying that the projects should be structured in a
certain way (tbachman,
17:25:48)
- 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)
- 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)
- ttkacik says the jacoco reports which measures
the code coverage across all the reports, it looks different
(tbachman,
17:27:26)
- colindixon asks if you can pull out code
coverage from jacoco reports more easily than sonar (tbachman,
17:27:48)
- ttkacik says jacoco reports are used by
sonar (tbachman,
17:28:07)
- 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)
- 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)
- regXboi is concerned about this requirement
driving projects just to meet this requirement, rather than driving
“better testing” (tbachman,
17:30:06)
- 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)
- 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)
- 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)
- regXboi suggests that he’d like to use the
minimum of JaCoCo and sonar for code coverage (colindixon,
17:34:10)
- regXboi also notes he is cynical that people
will game the system if they get the chance (phrobb,
17:34:59)
- regXboi asks if we’ve resolved the version
bumping and branch cutting isses, colindixon says no (colindixon,
17:36:11)
- 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)
- 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)
- 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)
- 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)
- it seems like there is consensus to do branch
cutting and version bumping at the same time to avoid issues
(colindixon,
17:44:19)
- 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)
- regXboi notes that offset 0 projects suffer a
halt of 4/5 weeks of calendar time (tbachman,
17:45:37)
- ACTION: tony to send
out an e-mail explaining his alternative solution to version bumping
and branch cutting (colindixon,
17:48:04)
- 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)
- 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)
- ACTION: regXboi to
send out email on continuous release process (tbachman,
17:51:58)
- ACTION: colindixon to
resolve the scope change issue on the mailing list (colindixon,
17:52:10)
- 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)
- 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)
- 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)
- ACTION: colindixon to
remove the TODO about scope changes, because it is and wil be
resolved by the TSC (colindixon,
17:56:06)
- ACTION: colindixon to
remove the TODO about what adequate docuementation should be defined
as (colindixon,
17:57:21)
- 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)
- 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)
- 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)
- colindixon asks if we have something we can
articulate as a requirement for security (tbachman,
18:00:33)
- 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)
- 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)
- ACTION: colindixon to
make the above changes and send out a mail asking for a vote this
week (colindixon,
18:02:51)
- mohnish asks if we should make “not fixable” in
terms of security less ambigous (colindixon,
18:04:38)
- 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)
- cookies (colindixon, 18:05:19)
Meeting ended at 18:05:22 UTC
(full logs).
Action items
- colindixon to try to find somebody to help with documenting the general procedure for the platform upgrade from Helium to Lithium (for SR1)
- ChrisPriceAB to work with rovarga, jmedved, et. al. to look into leveraging OPNFV infrastructure for performance measurements and
- phrobb to investigate what it takes to get to the license for JIRA, and what the licence would be for
- colindixon and dfarrell07 to talk about automating notifiying projects of test failures
- #action colindixon check if gzhao sent out exact cutoff dates/times for Lithium SRs and get him to if he hasn’t
- colindixon to send mail asking somebody to represent Martin Sunal’s case as a committer on SXP at a future TSC call
- phrobb and gzhao to beat the bushes to try to get cherry-picks out
- colindixon to start a thread on how long to support stable/helium (also discuss the previous vote)
- 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
- 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
- tony to send out an e-mail explaining his alternative solution to version bumping and branch cutting
- regXboi to send out email on continuous release process
- colindixon to resolve the scope change issue on the mailing list
- colindixon to remove the TODO about scope changes, because it is and wil be resolved by the TSC
- colindixon to remove the TODO about what adequate docuementation should be defined as
- colindixon to add a note that the TSC must vote on whether ot not each stable feature has met the requirements
- 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 to make the above changes and send out a mail asking for a vote this week
Action items, by person
- colindixon
- colindixon to try to find somebody to help with documenting the general procedure for the platform upgrade from Helium to Lithium (for SR1)
- colindixon and dfarrell07 to talk about automating notifiying projects of test failures
- #action colindixon check if gzhao sent out exact cutoff dates/times for Lithium SRs and get him to if he hasn’t
- colindixon to send mail asking somebody to represent Martin Sunal’s case as a committer on SXP at a future TSC call
- colindixon to start a thread on how long to support stable/helium (also discuss the previous vote)
- colindixon to resolve the scope change issue on the mailing list
- colindixon to remove the TODO about scope changes, because it is and wil be resolved by the TSC
- colindixon to remove the TODO about what adequate docuementation should be defined as
- colindixon to add a note that the TSC must vote on whether ot not each stable feature has met the requirements
- 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 to make the above changes and send out a mail asking for a vote this week
- dfarrell07
- colindixon and dfarrell07 to talk about automating notifiying projects of test failures
- gzhao
- #action colindixon check if gzhao sent out exact cutoff dates/times for Lithium SRs and get him to if he hasn’t
- phrobb and gzhao to beat the bushes to try to get cherry-picks out
- jmedved
- ChrisPriceAB to work with rovarga, jmedved, et. al. to look into leveraging OPNFV infrastructure for performance measurements and
- phrobb
- phrobb to investigate what it takes to get to the license for JIRA, and what the licence would be for
- phrobb and gzhao to beat the bushes to try to get cherry-picks out
- 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
- regXboi
- regXboi to send out email on continuous release process
- UNASSIGNED
- 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
- tony to send out an e-mail explaining his alternative solution to version bumping and branch cutting
People present (lines said)
- tbachman (75)
- colindixon (57)
- odl_meetbot (13)
- dfarrell07 (12)
- regXboi (11)
- abhijitkumbhare (8)
- phrobb (7)
- mohnish (5)
- ebrjohn (1)
- dlenrow (1)
- jmedved (1)
- LuisGomez (1)
- odl-casey (1)
- gzhao (0)
Generated by MeetBot 0.1.4.