Planned Review Date: 2012-03-23
Communication Channel: linuxtools-dev@eclipse.org (https://dev.eclipse.org/mailman/listinfo/linuxtools-dev)
Authors: Andrew Overholt <overholt redhat com>, Francois Chouinard <fchouinard at gmail.com>, Otavio Pontes <obusatto@linux.vnet.ibm.com>
Introduction
- The Linux Tools project is a two-faceted project
- Firstly, it provides tools and frameworks for writing tools relevant to Linux developers.
- Secondly, it provides a place for Linux distributions to collaboratively overcome issues surrounding distribution packaging of Eclipse technology. The project produces both best practices and tools related to packaging.
Features
- a framework for integrating native profiling tools with the CDT
- visualization, fetching, and control of LTTng traces
- GCov code coverage tool integration
- GProf integration including function-based profiling and integration with the CDT
- an RPM .spec editor with rpmlint integration
- plugins integrating the OProfile profiler with the CDT
- a Zest (GEF)-powered C/C++ call graph integrated with the CDT, powered by SystemTap
- GNU Autotools CDT additions
- plugins bridging the CDT's hover help functionality with the various open source API documentation formats and tools; called libhover
- Valgrind integration for memcheck, massif, cachegrind and helgrind
- a tool to help building and packaging Eclipse plugins as RPMs named RPM Stubby
- change log management tools
- an editor, launcher, and data visualizer for SystemTap scripts
New in 0.10
- RTD Proxy plugin used to implement a remove version of the local plugins
- BIRT chart api replaced by SWTChart in BIRT plugin
- More New and Noteworthy for 0.10
Non-Code Aspects
APIs
- Being a pre-1.0 release, our APIs are subject to change.
- We continue to internalize unnecessarily public APIs and have done much work in this area for 0.8 and 0.9. We have also worked to further reduce usage of internal APIs from underlying projects.
- We will converge on stability – and document such stability – in our APIs well before our 1.0 release.
- Post-0.10, we will be tightening our APIs to aid our growing community of adopters.
Architectural Issues
- Ongoing work to integrate with tracing and profiling toolkits will enable us to have more extensible frameworks with exemplary implementations. Integration for the profiling tool 'perf' has recently been done by a community member using our profiling framework.
- Despite being user-focused, we have a few components which provide extension points:
- our profiling tool framework whose use is demonstrated by our OProfile and Valgrind integration plugins
- our ChangeLog plugin which allows for extensible parsers, formatters, and editors. The extensibility of formatters is demonstrated by our RPM .spec editor
- our libhover component. This plugin provides an extension point that defines a common documentation format for C library hover help
- our LTTng component. This plugin provides an extension point to integrate any type of trace and an extension point for producing UML2 sequence diagrams from traces
- Our releases thus far have been well-received and at present have satisfied users. This 0.10 release will hopefully grow our base of satisfied users. In addition to improved quality through bug fixes, we hope that the increased exposure of being a part of Indigo will garner more happy users.
- Due to the large number of people packaging software for RPM-based distributions, our .spec editor has become one of our more popular features.
- The in-line warnings and error checking as well as templates and completion are incredibly useful features.
- Our work integrating native profiling tools like LTTng, OProfile, and Valgrind has been introduced to excited audiences. We aim to bring the power of these tools into the IDE while making them trivial to use. Developers making use of our tools will be able to focus on their own projects and not on setting up the underlying tools.
End-of-Life
- We have no end-of-life issues to discuss at this time.
Bugzilla
- For our 0.10 release we will have 0 outstanding release-blocker bugs.
- We closed or resolved over 38 bugs during our 0.10 release cycle:
https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Technology&product=Linux+Tools&target_milestone=0.10.0&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0
Standards
- Our project conforms to the following standards, some of which are ad-hoc and some which are more well-defined:
- Fedora RPM packaging guidelines
- Informal conventions around use of the GNU Autotools
- GNU ChangeLog formatting
- LTTng trace format
UI Usability
- Our project aims to conform to the Eclipse user interface guidelines.
- All of our user interface components support keyboard navigation.
- We now support interactivity of our Valgrind BIRT-generated charts and intend on further increasing our accessibility.
- All of our strings are externalized but we currently have no language packs
- Our strings are registered in Babel for use by translators
Schedule
- We plan on having our 0.10 release as an intermediate step before Juno
- Our project aims to release minor releases (0.6, 0.6.1, 0.7, 0.8, etc.) every two to three months
- We plan to spend a lot of time over the next year standardizing our APIs and getting ready for a 1.0 as part of Juno
Communities
- Our project has a strong relationship with the various Linux distributions (Fedora, Mandriva, Debian, Ubuntu, etc.) with many using our eclipse-build project's output for their Eclipse SDK packages
- The majority of our project's interactions occur on IRC (#eclipse-linux) and our mailing list (linuxtools-dev@eclipse.org)
- We have a centralized update site and use eclipse.org bugzilla for all of our planning and bug tracking
- We make use of our newsgroup for user feedback
- Our project members often speak at conferences such as EclipseCon, the Red Hat Summit, etc.
- Our team members maintain the following blogs:
- We interact often with the CDT project and make use of the BIRT, GEF, and CDT projects
- We are growing our community of adopters
IP Log
- Our IP log including information about all CQs, external contributions, and committers can be found here
- A copy of our 0.10 IP log, once approved by the Eclipse Legal team, will be archived here: