Jump to: navigation, search


Welcome to the OpenDaylight Technical Steering Committee (TSC) Wiki. This page hosts all information associated with the OpenDaylight TSC including meeting schedules, Agendas, and Minutes. To see a list of who is on the TSC along with their Biographies, please go to the TSC page at OpenDaylight.org. To contact the TSC, send an email to the TSC mail list.

Meeting Schedule and Logistics

TSC meetings are held weekly for one hour on Thursday mornings at 10:00am Pacific Daylight Time with the exception of the 4th Thursday. On the 4th Thursday of each month the TSC will host a meeting at 3:30am UTC meeting. Meetings are held using Zoom for screen sharing and audio and IRC for recording meeting minutes.

Standard Meeting

  • Meeting URL: Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/219174946
  • Access Information
    • Meeting number: 219 174 4946
    • Meeting password: This meeting does not require a password.
  • Audio Connection

APAC Meeting (Held every 4th Thursday)


The next TSC meeting is scheduled December 14th, 2017 at 10a Pacific]with the following agenda:

  • Start the Recording
  • Show the Antitrust Policy
  • Agenda Bashing, Roll Call, Action Items (all, 5 minutes)
  • Updates (all)
  • Committer Promotions (All, 0 minutes)
    • none this week
  • Creation Reviews: (All, 0 minutes)
  • Graduation Reviews (All, 0 minutes)
    • none this week
  • Archive Reviews: (All, 0 minutes)
    • none this week
  • Discussions (all, 15 minutes)
    • Groups.io Vote (Casey, 10 minutes)
    • Placeholder for Feb 15 meeting (initial discussion Feb 8): dlux and dluxapps PTL after Maxime stepping out. DLUX project health.
    • Other topics: (all, 5 minutes)</b>
      • Releases/distributions refactoring discussions
      • Project Goals for 2018 (remind folks to review)
      • Groups.io discussion and condensing mailing lists
      • OpenDaylight Support routes - Socializing Stack Exchange
      • Carbon/Nitrogen/Oxygen Service Release dates revision. Please refer Calendar View of Dates and Draft Proposal by Kit
    • Yet-to-be-done action items are restated here
      • abhijitkumbhare to initiate an email thread regarding the Singularity Principle
      • CaseyODL to go write a straw-man/skeleton "How to get help" docs page in docs repo via Gerrit/Rst
      • rovarga to revive stalled discussions on TrieMap after he is back from the vacation
      • rovarga_ to reach out to Daniel Malachovsky
    • Quick Check on Intended Topics for Coming Weeks (Cleanup)
      • Project Goals and Objectives for 2018 (Casey)
      • Singularity Principle (Casey)
      • TSC Membership - language for what to do with TSC vacancies - followup on the action to bring it up with the board (have we brought it up?)
    • TrieMap project proposal
      • Email discussion seems stalled - #action Robert to revive?
    • Liblldp project proposal
      • Email discussion seems stalled - #action Sam to revive?
    • Inter-project dependencies
      • Email discussion seems stalled - #action Stephen/Robert to revive?

Intended Topics for Coming Weeks

For 9/28/2017 (APAC-time):

  • Project Proposals
    • None outstanding

Once Board gets back to us:

Future Topics

Archived Topics

TSC Membership

The TSC is comprised of technical leaders within the OpenDaylight development community and are elected annually. Please refer to the TSC Election Process page for further details.

The TSC is led by the TSC Chairperson. The TSC Chair is elected annually: TSC Chair Election Process

The current members of the TSC can be viewed here.

TSC Procedures and Processes

Project Proposals and Creation Reviews

The project proposals page includes lots of useful information including how to propose a project, how to schedule and what to expect from your creation review, as well as what to do after a successful creation review.

Split-out Projects and Lifecycle States

This mailing list thread and section 2 of this TSC meeting established the following basic outline:

  • There is no guarantee that the split-out project will retain the lifecycle state of the project it split out from.
  • In general, the new project can request to have the relevant reviews to get to their desired lifecycle state at the same time as their creation review. For example, a project could have a creation review and a graduation review on the same day to become a mature project assuming the TSC agrees the project meets the requirements.

How To Run an Election within your project

A common reason to run a Condorcet Election within a project is to elect a Project Lead (also called Project Technical Lead or PTL). Please refer to the following page for detailed instructions on running such an election.

Best practices for preventing/handling cross-project breakages

As approved in the 2/4/2016 TSC meeting, the TSC approved the best practices as described in this mail and restated here:

  1. Broadly, our culture should be one of respecting the time and pain of other developers.
    1. Ideally, the "don't break userspace!" mantra of Linux would translate here into "don't break downstream!"
  2. Do your best to test code (across projects) before it's merged.
    1. If the ODL kernel depends on something you're changing, compiling the whole kernel with the change locally to make sure it builds seems to make sense
  3. If a change is believed to potentially problematic, test it more intensively
    1. At least run the test-integration keyword to see what happens.
    2. Ideally run autorelease with the patch.
      • [keeping autorelease working better as a high priority would be a good technical change]
      • [we should provide more streamlined ways to do this will be important, e.g., the autorelease validate that we've created]
    3. Announce it as a Weather event and via e-mail at least a week in advance of it being merged to give downstream projects time to test.
    4. it should be merged earlier in the week, e.g., Monday or Tuesday, to provide time when developers will be around to catch/fix any fallout
  4. If, after a change has been merged, downstream projects complain that they are having issues, either:
    1. provide patches to get them back up and working if they're simple.
    2. revert the change for some specified period of time while downstream projects and the community can figure out what to do.
      • [such breakages should be reported in a timely fashion, e.g., within 48 hours]
      • [upstream projects should have some time to analyze the breakage and either fix it or revert the troublesome patch, e.g., 24 hours]
    3. downstream projects should not be able to indefinitely stall a change.
      • [after some reasonable period of time, e.g., 2 weeks, downstream projects are expected to be able to make reasonable changes with help to allow a change to be merged]
      • [if the downstream project feels the changes aren't reasonable and it can't be resolved between projects, the TSC can adjudicate]

Committer promotion process for contributors

See the committer promotion process page.

Keeping Clean Committer Lists

The TSC asks that projects (on an ongoing basis or every approximately 6 months), please do the following.

  • Identify committers who have been inactive for more than 6 months
  • Reach out to them to understand if they would like to step down or if there are compelling reasons they would like to stay a committer despite their inactivity.
  • In the event of a non-response despite repeated attempts to contact the committer and/or the committer asks to step down from the role, have them removed as a committer and notify the TSC.
  • Ensure that everyone knows the TSC is willing to arbitrate any disputes and note that this process is intended to ensure the committer list better reflects reality rather than anything political.

This was agreed to in the April 7, 2016 TSC meeting. Please see items 2.i and 2.j.

Committer Removal Process

Note: According to the TSC charter, the power to remove committers lies with project leads. However to log these actions and provide visibility, the TSC asks to be informed (by mail to the TSC mailing list) of these events and provides the following guidelines.

In general, a project seeking to remove a committer should do so with consent of the committer being removed. This has happened several times in the past, most commonly with the committers themselves instigating the process.

If a committer would like to be removed, the general approach is:

  1. The committer should e-mail the project's -dev mailing list letting the project and other committers know their intention.
    • This is useful both to keep people in the loop and to potentially address any issues that might cause the committer to stay.
    • DO NOT try to coerce a committer who wants to leave into staying if they would rather not.
  2. Assuming the project and committer agree that the removal makes sense, the project lead should send an email to the TSC mailing list notifying the TSC of the removal.
    • Make sure to include a link to the public e-mail documenting the committer asking to be removed.
  3. Finally, the committer must notify the helpdesk (helpdesk@opendaylight.org) with the request to have their committer privileges removed for that project.

If the project instigates the removal, the general approach is:

NOTE: In general, the TSC advises against removing committers without them instigating the process for reasons other than inactivity.

  1. The project lead should privately reach out to the committer and explain what's going on and get their opinion on how to proceed.
    • This should be done privately first to avoid any embarrassment if something is merely a misunderstanding.
    • DO NOT try to coerce them into stepping down.
    • In most cases, people that have simply not had as much time as they expected are happy to step down voluntarily.
  2. Assuming they are willing to step down, make sure they send an e-mail to the project's -dev mailing list stating that publicly.
  3. The project lead should send an email notifying the TSC to remove the committer to the TSC mailing list
    • Make sure to include a link to the public e-mail from the committer saying they would like to step down.
  4. Finally, open a helpdesk (helpdesk@opendaylight.org) ticket to have their committer privileges removed for that project including the link to the e-mail sent to the TSC mailing list.

If the project and committer disagree:
In the event that the committer can't be reached or is unwilling to step down, the TSC charter states that "A Committer who is disruptive, or has been inactive for an extended period (e.g., six or more months) may have his or her Committer status revoked by the project leads." We would like to avoid doing this in a non-consensual way if at all possible, so please reach out to the TSC to figure out how to proceed. If you would rather figure out the right approach in private first, feel free to e-mail the TSC chair directly.

The TSC further confirmed during the 3/17/2016 meeting that "the TSC feels like this doesn't need a vote, PTLs can remove inactive committers at their discretion, but the TSC strongly encourages that people let the TSC know, and also notes the TSC can resolve any disputes of this"

Developer Design Forum Attendance Policy

If the registrant indicates that they contributed a patch to the previous release (in this case Boron), then they are immediately registered for the event.

If the registrant indicates that they have not contributed a patch in the previous release, then we ask them to tell us why they want to attend. From that we may start a dialog so that we are sure they understand the purpose of the DDF so that no one's time or resources are wasted. If there is any value they can gain, and/or provide by participating, we default to granting them access to the DDF.

Escalation Process for issues and disputes

While it is never explicitly stated, throughout our governance there is the general idea of a hierarchy to resolve any issues or disputes something like this:

  1. interactions between members of the community with no formal process
  2. resolution at the project-level by committers and PTLs of projects as listed on each project's main page; here is a list of those pages.
  3. resolution at the TSC-level by TSC members
  4. resolution at the board-level by board members

In addition, note that, the OpenDaylight Foundation Executive Director and staff are available to facilitate interactions at any stage in the process.

Project Archiving and Termination Reviews

This content was imported from Archive Proposals and can be viewed in it's full context there.

According to the OpenDaylight Project Lifecycle and Releases document, a project can be moved to the Achived state by a Termination Review. The termination review can be instigated either by a vote of the project committers or by the TSC. For the TSC to instigate the termination review, the project must have no remaining committers or have had no commits to their repository for more than 18 months. Note: it is useful for a project to wait until the end of support of the the last release it participated in to avoid having to make changes to an archived project, e.g., to fix bugs.

In either event, a Termination Proposal must be posted for two weeks containing the following information:

  1. That the project is being terminated
  2. A description of the impact on other projects, users, and communities as well as how they will be mitigated
  3. Where the project will be archived to

Archival Reviews

Affinity Metadata ServiceArmouryDefense4All
DiscoveryIntegrationOpenDaylight SDN Controller Platform (OSCP)
OpenDaylight ToolkitOpen DOVESouthbound plugin to the OpenContrail platform

Meeting Minutes

A complete list of the IRC TSC meeting minutes and logs since July 24th, 2014 should be here:

A complete list of archived meeting recordings can be found here.

All TSC Wiki Pages