Revision as of 13:27, 5 June 2014

TCF 1.3 DRAFT plan

NOTE: This is a DRAFT plan and none of the items below are committed.

Compatibility

We will be shooting for a TCF 1.3 version, ie keep API's compatible:

• TCF protocol must remain 100% compatible with TCF 1.2 (it's part of the TCF value proposition)
• TCF Java API must remain 100% binary compatible (we have clients coding against it)
• TCF Python and C API should remain 100% compatible (we have clients but this is source compatibility so they can rebuild or use version checks)

Timing

• TCF 1.3 shall adopt the CDT's "rapid release" model and release with Eclipse Luna SR1 in September 2014.
• TCF 1.4 shall come with Eclipse Luna SR2 (Feb 2015)
• TCF 1.5 or 2.0 shall come with Eclipse Mars (June 2015)

This is a "Plan of Intent". It's possible that a release may be delivered earlier or later as needed by the community or the TCF committers.

API Compatibility is planned for the "Luna" release lifecycle, but not yet decided for Mars.

Requirements and Dependencies

• TCF 1.3 primary target will be CDT-8.4 on Eclipse 4.4 Luna
  • Eclipse 3.8 support will likely be dropped sine CDT-8.4 doesn't support Eclipse 3.x any more
  • Eclipse 4.2.2 may continue to be supported as the most recent Eclipse Platform LTS stream (bubble item: to be decided)

• Java 7 will be the Bundle-RequiredExecutionEnvironment for Java code.

Proposed Themes

Most of the themes are really a carry-over from the TCF 1.2 Plan. Although we have made great progress on each of the themes, our focus and priorities haven't shifted.

Robustness and Matrix Coverage

Interested Parties: All

• We will continue making TCF a rock-solid commercial-grade debug solution and increase its coverage of target architectures and compilers.
  • Increase coverage of supported ELF tags and ELF format variants in the symbol and DWARF readers
  • Fix defects and increase test coverage

Improve Unittest coverage at Eclipse.org

Interested Parties: Wind River, Xilinx

• With tcf-1.2 automated unit testing of both Java and C Agent code on the Eclipse.org servers has been introduced
  • We want to extend automated testing and improve Hudson feedback on test failures (graphs, trends)
  • We want to add automated testing for the Python API's

Tracing and Profiling API's

Interested Parties: Freescale, Xilinx, WindRiver

• There is interest from multiple parties in adding standardized tracing and profiling API's to TCF.
• Adding support for "perf" based profiling on Linux is being discussed.

Collaborate with Linux Distro Builders

Interested Parties: Wind River

• For widespread adoption, a TCF agent should come out-of-the-box with Yocto, Buildroot, Raspbian and potentially other Linux distros.

Collaborate with gdb and Multicore Association

Interested Parties: Wind River, Xilinx

• gdb is very strong thanks to its rich and well-known command-line and scripting support; but it has performance problems on multicore embedded systems since the "gdbserver" protocol is very limited. The gdb community is thinking about a new remote protocol. TCF seems to exactly match their needs. Collaboration should be considered.

• The Multicore Association TIWG is working on a generic protocol for tooling. TCF seems to be a very good match for their needs. Continue exchange and collaboration.

Further Improve Usability

Interested Parties: Wind River

• We'll want to further improve the out-of-box experience and usability for TCF-based products.
• Add more HOWTO's and out-of-box documentation instructions like the Raspberry Pi HOWTO
• Consider a pre-built package similar to the Buildroot Eclipse Tools Package
• TCF is strong in language bindings and scripting. Provide more examples for how to use the TCF Python and Lua bindings.