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.
- 1 Meeting Schedule and Logistics
- 2 Agenda
- 3 TSC Membership
- 4 TSC Procedures and Processes
- 4.1 Project Proposals and Creation Reviews
- 4.2 How To Run an Election within your project
- 4.3 Best practices for preventing/handling cross-project breakages
- 4.4 Committer promotion process for contributors
- 4.5 Keeping Clean Committer Lists
- 4.6 Committer Removal Process
- 4.7 Developer Design Forum Attendance Policy
- 4.8 Escalation Process for issues and disputes
- 4.9 Project Archiving and Termination Reviews
- 5 Meeting Minutes
- 6 All TSC Wiki Pages
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 WebEx for screen sharing and audio and IRC for recording meeting minutes.
- Meeting URL: Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/896670700
- Access Information
- Meeting number: 896 670 700
- Meeting password: This meeting does not require a password.
- Audio Connection
- Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
- iPhone one-tap (US Toll): +16465588656,896670700# or +14086380968,896670700#
- International numbers available: https://zoom.us/zoomconference?m=ogJPle7qN6xSiNDa8J8Wb8TDRvS48PiQ
APAC Meeting (Held every 4th Thursday)
- Meeting URL: Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/423359597
- Access Information
- Meeting number: 423 359 597
- Meeting password: This meeting does not require a password.
- Audio Connection
- iPhone one-tap (US Toll): +14086380968,423359597# or +16465588656,423359597#
- Dial: +1 408 638 0968 (US Toll) or +1 646 558 8656 (US Toll)
- International numbers available: https://zoom.us/zoomconference?m=xcQzDFN9dplmHX-N_5L36fTJg-7jDSyH
The next TSC meeting is scheduled for June 22nd, 2017 at 3:30a UTC with the following agenda:
- Start the Recording
- Agenda Bashing, Roll Call, Action Items (all, 5 minutes)
- Call for any new topics for the agenda
- Yet-to-be-done action items are restated here
- Last meeting's minutes
- Updates (all, 10 minutes)
- TSC mailing list votes and discussions
- Events (Phil)
- Boron (An/Thanh)
- Carbon (An/Thanh)
- Nitrogen (An/Thanh)
- System Integration and Testing (Jamo)
- Infrastructure (Andrew/Thanh)
- Committer Promotions (All, 0 minutes)
- none this week
- Creation Reviews: (All, 30 minutes)
- Graduation Reviews (All, 0 minutes)
- none this week
- Archive Reviews: (All, 0 minutes)
- none this week
- Security Mailing List (Robert/Stephen/All, 15 minutes)
- How can we get more people on the team/list (Robert)
- How do we track/handle CVEs (Stephen)
- TSC Membership (0 minutes)
Intended Topics for Coming Weeks
June 22nd (APAC-time) meeting:
- Creation Reviews: (All, 0 minutes)
Once Board gets back to us:
- Singularity Principle
- Asking the Board to Remove the Singularity Principle
- waiting for feedback from the board sometime in early September per bullet 6 here of the 8/4/2016 TSC mintues
- Modifications to the Graduation Review
- Committer Promotions (All, 5 minutes)
- Creation Reviews:
- Graduation Reviews
- Archive Reviews
- Adding features between releases (All, ?? minutes)
- Do we want a way to do intermediate releases that add features, e.g., to provide features to important downstream projects
- Board Requests: (All, 15 minutes)
- Progress on Technical Debt/Integration (10 minutes)
- Resolving cyclic dependencies (Thanh, 5 minutes)
- OpenDaylight Best Practices (Colin/all, 10 minutes)
- Developer Best Practices
- Logging Best Practices
- General Style Guidelines
- OpenDaylight Java Style
- CrossProject:HouseKeeping Best Practices Group:Main
- CrossProject:HouseKeeping Best Practices Group:Project layout
- CrossProject:HouseKeeping Best Practices Group:Versioning
- CrossProject:HouseKeeping Best Practices Group:Integration Test
- CrossProject:HouseKeeping Best Practices Group:Whitespace
- Proposed Committer Checklist
- Additional points
- Keep the "download, unzip, and just run" deployment model, i.e., allow for external dependencies, but don't require them
- Keep things cross-platform, i.e., avoid JNI if you can
- Post-Helium Release Hot Issues
- Code Quality
- and its relationship to "core" projects
- TSC Operation, Project Scope and promotion framework(s)
- General Project Scope: What are the important ("core") components of ODL?
- Need to discuss and build a framework around
- What duplicative/overlapping functionality and goals are to be allowed within Incubation projects?
- How is that duplication resolved as one or more projects move from incubation to mature?
- Providing clear boundries for projects on a case by case basis regarding scope (based on the framework that is TBD) so that projects are clear on what they can and cannot do
- More generally, additional clarity and process around project promotion
- Code Quality
- TSC/TWS call timing/timezones
- API Review Process
- Waiting on External Actions:
- Code Maturity and Lifecycle Issues
- Helium (and future release) Support Lifetime (Ryan/all, 10 minutes)
- Promotion Process (all, 15 minutes)
- Encouraging projects to move to mature
- How we want to deal with overlapping functionality and/or resolve the "singularity" clause in the TSC policy.
- Discussion: Proposals for more detailed guidelines for promotion from incubation
- Future Release Mechanics (All, 15 minutes)
- Is a simultaneous release tenable at our current (and future size).
- If not, what is the replacement?
- See thread here: https://lists.opendaylight.org/pipermail/tsc/2015-January/002410.html
- Also see notes/recording/slides from the 2/2/2015 TWS Meeting
The TSC is comprised of technical leaders within the OpenDaylight development community coming from one of three groups.
- Project Leaders from OpenDaylight projects designated as "Core" projects within the OpenDaylight Project Lifecycle
- Two Committer-At-Large members elected annually: Committer-At-Large Election Process
- 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
- 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
- Broadly, our culture should be one of respecting the time and pain of other developers.
- Ideally, the "don't break userspace!" mantra of Linux would translate here into "don't break downstream!"
- Do your best to test code (across projects) before it's merged.
- 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
- If a change is believed to potentially problematic, test it more intensively
- At least run the test-integration keyword to see what happens.
- 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]
- 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.
- 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
- If, after a change has been merged, downstream projects complain that they are having issues, either:
- provide patches to get them back up and working if they're simple.
- 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]
- 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:
- 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.
- 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.
- Finally, the committer must notify the helpdesk (email@example.com) 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.
- 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.
- Assuming they are willing to step down, make sure they send an e-mail to the project's -dev mailing list stating that publicly.
- 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.
- Finally, open a helpdesk (firstname.lastname@example.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:
- interactions between members of the community with no formal process
- 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.
- resolution at the TSC-level by TSC members
- 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:
- That the project is being terminated
- A description of the impact on other projects, users, and communities as well as how they will be mitigated
- Where the project will be archived to
|Affinity Metadata Service||Defense4All||Integration|
|OpenDaylight SDN Controller Platform (OSCP)||OpenDaylight Toolkit||Open DOVE|
|Southbound plugin to the OpenContrail platform|
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.
June 15th, 2017
June 8th, 2017
Jun3 1st 2017
- No meeting on account of DDF
May 25th 2017
March 16th, 2017
March 14th, 2017
- Special Meeting of the TSC Release Workgroup
- WebEx Recording
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