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 8:30pm Pacific Daylight Time meeting. Meetings are held using WebEx for screen sharing and audio and IRC for recording meeting minutes.

Standard Meeting

APAC Meeting (Held every 4th Thursday)


The next TSC meeting is scheduled for April 20th, 2017 at 10:00p pacific time with the following agenda:

Intended Topics for Coming Weeks

Once Board gets back to us:

Future Topics

Archived Topics

TSC Membership

The TSC is comprised of technical leaders within the OpenDaylight development community coming from one of three groups.

  1. Project Leaders from OpenDaylight projects designated as "Core" projects within the OpenDaylight Project Lifecycle
  2. Two Committer-At-Large members elected annually: Committer-At-Large Election Process
  3. One member designated by each Platinum Member of the OpenDaylight Project

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.

2014 TSC Chair Election

The 2014 TSC Chair election has concluded. Colin Dixon is the new TSC Chair

2014 Committer-At-Large TSC Elections

The 2014 Committer-At-Large Elections have concluded. The 2014 Committer-At-Large TSC Members are:

  • Colin Dixon
  • Ed Warnicke

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

Termination Proposals

TCPMD5:Termination Proposal

Archival Reviews

Affinity Metadata ServiceDefense4AllIntegration
OpenDaylight SDN Controller Platform (OSCP)OpenDaylight ToolkitOpen DOVE
Southbound 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.

Specific Dates

March 16th, 2017

March 14th, 2017

March 9th, 2017

March 2nd, 2017

February 24th, 2017

February 9th, 2017

February 2nd, 2017

January 26th, 2017

January 19th, 2017

January 12th, 2017

January 5th, 2017

December 22nd, 2016 (APAC Meeting)

December 15th, 2016

December 8th, 2016

December 1st, 2016

November 17th, 2016

November 10th, 2016

November 3rd, 2016

October 27th, 2016

October 20th, 2016

October 13th, 2016

October 6th, 2016

September 22nd, 2016

September 15th, 2016

September 8th, 2016

September 1st, 2016

August 25th, 2016

August 18th, 2016

August 11th, 2016

August 4th, 2016

July 28th, 2016

July 21st, 2016

July 14th, 2016

July 7th, 2016

June 23rd, 2016

June 16th, 2016

June 9th, 2016

June 2nd, 2016

May 26th, 2016

May 19th, 2016

May 12th, 2016

May 5th, 2016

April 21st, 2016

April 14th, 2016

April 7th, 2016

March 31st, 2016

March 24th, 2016

March 17th, 2016

March 10th, 2016

March 3rd, 2016

February 25th, 2016

February 18th, 2016

February 11th, 2016

February 4th, 2016

January 28th, 2016

January 21st, 2016

January 14th, 2016

January 7th, 2016

All TSC Wiki Pages