Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "TCF/DraftPlan13"

< TCF
(TCF 1.3 DRAFT plan)
Line 6: Line 6:
  
 
<font size="+2" color="red"><b>NOTE: This is a DRAFT plan and none of the items below are committed.</b></font>
 
<font size="+2" color="red"><b>NOTE: This is a DRAFT plan and none of the items below are committed.</b></font>
 +
 +
See also [[TCF/DraftPlan12]], [[TCF/NewIn12]], [[TCF/NewIn13]]
 +
  
 
==Compatibility==
 
==Compatibility==
Line 12: Line 15:
  
 
* TCF protocol must remain 100% compatible with TCF 1.2 (it's part of the TCF value proposition)
 
* 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 Java API must remain 100% binary compatible with TCF 1.2 (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)
 
* 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)
 +
 +
Tested Operating Environments:
 +
 +
* Java 7 will be the Bundle-RequiredExecutionEnvironment for Java code.
 +
* We want to continue with an "N-1" dependency strategy: latest TCF will work on top of the current and previous versions of Platform and CDT:
 +
** Primary: https://hudson.eclipse.org/tcf/ job against Eclipse 4.4 Luna + CDT 8.4 Luna + Java 7
 +
** Secondary: https://hudson.eclipse.org/tcf/ job against Eclipse 4.3.2 Kepler SR2 + CDT 8.3 Kepler SR2 + Java 7
 +
 +
* To be discussed:
 +
** ''Do we need a test job against Eclipse 4.4.1 Luna SR1 + CDT 8.5 ?''
 +
** ''Do we need a test job against Eclipse 4.5 Mars ?''
 +
** ''Do we need any test job using Java 8 ? - Linuxtools project has reported that Jobs with Java 8 run faster.''
 +
** ''Do we still need a test job against Eclipse 3.8.2 + CDT 8.3 ? - Note that CDT 8.4 only supports Eclipse 4.x''
 +
 +
 +
Obsoleted / Deprecated Functionality:
 +
 +
* Support for TCF agents older than 0.4 will be discontinued ([https://git.eclipse.org/c/tcf/org.eclipse.tcf.git/commit/?id=84240d1df6854ba7eb4990cc960255884b6b525a git commit on 16-May-2014).
 +
** TCF agent 0.4 was released in [http://git.eclipse.org/c/tcf/org.eclipse.tcf.agent.git/?h=0.4.0 september 2011]
 +
** It is noteworthy that OpenEmbedded / Yocto still seems to reference 4ef94ecb927a8912c3d79ce137182247786cff8f from July 2011:<br/>http://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
 +
  
 
==Timing==
 
==Timing==
Line 19: Line 43:
 
* TCF 1.3 shall adopt the CDT's "rapid release" model and release with Eclipse Luna SR1 in September 2014.
 
* 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.4 shall come with Eclipse Luna SR2 (Feb 2015)
* TCF 1.5 or 2.0 shall come with Eclipse Mars (June 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.
 
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.
Line 31: Line 55:
 
** Eclipse 4.2.2 may continue to be supported as the most recent Eclipse Platform LTS stream (bubble item: to be decided)
 
** 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==
 +
 
 +
===Make it Easier to Contribute===
 +
''Interested Parties:'' Wind River
 +
 
 +
* The [http://marketplace.eclipse.org/content/tcf-terminals TCF Terminals Marketplace Listing] has triggered quite some interest in the community, and a couple of bugs have been filed to improve usability of the local terminal.
 +
** We want to make it super easy for community members to contribute bug fixes or improvements to TCF, in order to ride the wave.
 +
 
 +
===Support CDT with the Target Explorer===
 +
''Interested Parties:'' Wind River
 +
 
 +
* Related to the "CDT LaunchBar" initiative, the CDT project has signaled interest in the TCF Target Explorer.
 +
** We want to support the CDT Community adopting Target Explorer
 +
** This may mean refactoring parts of TE in order to make it easier to consume
 +
** Also in line with the "easier to contribute" theme, ie make it easy for CDT committers to contribute patches if necessary.
 +
 
 +
===Collaborate with Linux Distro Builders===
 +
''Interested Parties:'' Wind River
 +
 
 +
* As it turned out that openembedded still references tcf-0.4 , we want to collaborate with Linux Distro builders helping them upgrade to a more recent version.
  
 
=Proposed Themes=
 
=Proposed Themes=

Revision as of 07:56, 5 August 2014

TCF 1.3 DRAFT plan

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

See also TCF/DraftPlan12, TCF/NewIn12, TCF/NewIn13


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 with TCF 1.2 (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)

Tested Operating Environments:

  • Java 7 will be the Bundle-RequiredExecutionEnvironment for Java code.
  • We want to continue with an "N-1" dependency strategy: latest TCF will work on top of the current and previous versions of Platform and CDT:
  • To be discussed:
    • Do we need a test job against Eclipse 4.4.1 Luna SR1 + CDT 8.5 ?
    • Do we need a test job against Eclipse 4.5 Mars ?
    • Do we need any test job using Java 8 ? - Linuxtools project has reported that Jobs with Java 8 run faster.
    • Do we still need a test job against Eclipse 3.8.2 + CDT 8.3 ? - Note that CDT 8.4 only supports Eclipse 4.x


Obsoleted / Deprecated Functionality:


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)


Proposed Themes

Make it Easier to Contribute

Interested Parties: Wind River

  • The TCF Terminals Marketplace Listing has triggered quite some interest in the community, and a couple of bugs have been filed to improve usability of the local terminal.
    • We want to make it super easy for community members to contribute bug fixes or improvements to TCF, in order to ride the wave.

Support CDT with the Target Explorer

Interested Parties: Wind River

  • Related to the "CDT LaunchBar" initiative, the CDT project has signaled interest in the TCF Target Explorer.
    • We want to support the CDT Community adopting Target Explorer
    • This may mean refactoring parts of TE in order to make it easier to consume
    • Also in line with the "easier to contribute" theme, ie make it easy for CDT committers to contribute patches if necessary.

Collaborate with Linux Distro Builders

Interested Parties: Wind River

  • As it turned out that openembedded still references tcf-0.4 , we want to collaborate with Linux Distro builders helping them upgrade to a more recent version.

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.

Back to the top