Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
CDT/summitecon2015
< CDT
Note: The contents of this page refer to a past CDT summit. For information on other and possible upcoming summits visit CDT/summits
Contents
CDT/Linux Tools/PTP/Trace Compass Summit at EclipseCon 2015
A one-day CDT/Linux Tools/PTP/Trace Compass Summit will be held at EclipseCon 2015 in San Francisco, CA, on Monday March 9th, 2015. This summit is open to registered attendees of EclipseCon. Please register here. It is an informal gathering of committers and contributors of the mentioned communities to discuss project direction, on-going work, proposed changes and enhancements, and any other topic of interest to the participants. It will be followed on the Tuesday by a CDT Theme Day of 7 official EclipseCon presentations related to these projects.
The below agenda may evolve as proposed topics are added and attendees sign-up.
To help structure the summit, please:
- add your name to the attendees section below
- add agenda items you would like to see discussed
Sponsors
Minutes
9:00-9:30
- Welcome and agenda adjustment
9:30-12:00
- Move to Java 8?
- Yes for CDT 8.8, right after the summer release of Mars.
- Platform is expected to also go to Java 8 after Mars.
- Recommended changes to make to CDT when on Java 8
- Lambdas
- Would be valuable to DSF
- Would need to adapt APIs to work with Lambda
- Existing code could remain the same but new code could then use Lambdas
- Readability? Experience shows it should be improved
- Error handling for RequestMonitor class would be difficult, may not be a good fit.
- Error handling could be done by having one method taking an error handler and a success handlers
- Default methods
- No more IMyInterface2 pattern
- We expect binary compatibility to be maintained in this case
- We would not remove existing IMyInterface2 to be nice to extenders but we could deprecate (some) of them.
- Lambdas
- API tooling support (e.g., handling of default methods)
- We don't know. We'll need to check early. If not, we need to revisit the use of default methods.
- Doing a 9.0 release to allow breaking APIs
- Must make a clear decision to allow work to begin ASAP
- Yes. We must confirm with the list.
- Announce in latest N&N.
- Create branch early.
- Branching strategy. How do we begin work early while allowing SR releases from master?
- Need a branch: APIBreak_9_0
- Keep *merging* master into APIBreak_9_0 to keep the two aligned
- Right after MarsSR2 (CDT 8.9) we bring APIBreak_9_0 to master, or even rename APIBreak_9_0 to master
- List of changes that should be looked at: https://wiki.eclipse.org/CDT/APIBreakages
- Must make a clear decision to allow work to begin ASAP
- Oomph demo: setting up Eclipse for CDT development in a few clicks
- Marc-Andre gave a nice little demo. Super easy to use!
- https://wiki.eclipse.org/Getting_started_with_CDT_development#Using_Oomph
- Eclipse installer that has been setup to handle CDT
- Will do entire CDT setup for contribution, including API baseline
- Setup file is at org.eclipse.cdt/releng/CDT.setup
- The Oomph catalogue points to the CDT.setup file in the CDT repo so all changes propagate from CDT automatically
- Existing setup file can be extended for a local team
- Existing git clone of CDT repo can be re-used when triggering a new installation through Oomph
- Other projects can do the same pretty easily
- We should add Gerrit push automatically (done by Marc-Andre during EclipseCon!)
- Standalone Debugger RCP: Discussions and/or demo.
- Product on top of the Standalone debugger
- Separate download than the CDT itself
- We will add it somehow to the CDT project pages, CDT downloads page
- Bugzilla backlog
- Entries should be marked as Enhancement when not a bug
- Suggestions for Enhancement and some bug fixes could be done by the person writing the bug or other contributors
- How do we motivate people to fix bugs? We could try the approach of the "Mars great fix contest"
- Point potential contributor immediately to CDT Oomph setup to get them started quickly
- Improve tools that help discover code (e.g., plugin spy, code references)
12:00-13:00
- Lunch
- Delicious salmon and nice conversations
13:00-15:00
- org.eclipse.remote and CDT
- Background on Target Management (TM)
- RSE - mostly UI not much of an API
- TCF - Framework to setup agents on remotes to provide different services
- TM Terminal - Rich terminal in eclipse
- PTP couldn't find the support they needed for remote stuff. They (Greg) built their own: org.eclipse.remote
- It has a strong API.
- It has some UI components as well
- Doug adjusted the o.e.remote API to allow for a service extensions layer
- There is a 'new' Remote Architecture that defines the following hierarchy:
- Connection Type
- Connection Type Service
- Connection Service
- Process Service
- UI components
- Preference page
- resource browser
- connections view
- remove file system view
- terminals view (from TM)
- Background on Target Management (TM)
- TM Terminals
- Original TM terminal vs TCF terminals
- TCF terminals uses tabs within the view (which is a tab itself). Opinions are mostly against the tabs-in-tab approach
- It is unclear to us what the TCF terminals does more than the TM terminal
- Launchbar
- Has its own repo (o.e.launchbar) now still part of CDT
- Moved it to use o.e.remote
- Plans to support remote launch over o.e.remote
- Launch configuration handling
- Filter box
- Draggable sash to selection how many in recent history
- Pre-builds before launches
- Automatically creates a launch config for a new project
- Launchbar buttons look like debugger buttons and that is sill a problem
- Could we disable the launchbar launch button after the first launch to avoid conflict and to simplify things for users? (Visual Studio does this)
- For the advanced user that needs a second session, they would fall back to using Eclipse's standard launching
- To improve, we can re-enable the button as soon as the user changes the configuration selected
- Or we can change icons
- Power on button?
- Greg sent a bunch of possible icons
- Toolchains: LLDB, Clang, Visual Studio
- Vladimir explained that with a simple patch, it is possible to get LLDB to work with CDT although no much advanced features have been tested
- Supporting LLDB directly without the MI layer would be interesting but requires someone to do it. There is concern it would be a lot of work.
- Content assist setting for completion
- Eclipse default setting is to complete after '.'
- People change it to use 'abc..yzABC..YZ' (i.e., with all letters)
- We should reduce the delay for auto-completion. Platform is going to 0. We should try things with our own users to see how it feels.
15:00-15:15
- Break - Chocolate and strawberries!
15:15-16:30
- JUnit on verify build (or any HIPP CDT builds)
- Figuring out test dependencies to the submitted patch would be great but complicated
- Instead, can we have a subset of tests that run faster for the verify builds and rely on the master build for the full tests
- Try not to run Debug tests on verify and see impact (Marc K tried with an 11 minute reduction from 44 min to 33 min)
- What is the next set of tests that would reduce build time?
- There are some System.GC() calls in the tests which slow down the tests. Can we remove?
- We should remove or reduce the sleep calls and use a loop instead
- Replace other sleeps with proper notifications
- Increase the number of concurrent builds?
- FindBugs, Sonar and general CDT quality
- Should be on verify to be noticed but add 20 minutes
- Can we limit what findbugs runs on?
- Can we ignore existing findbugs and track any new ones so we can have a baseline of 0?
- TM has gone down to 0 findbugs from over 400, how did they do that?
- Error Reporting tool from Mars (cameo by Alex Blewitt)
- Errors logged by CDT from any users summarized on a server and can be handled by committers
- Looked very useful and committers should look into it
- https://dev.eclipse.org/recommenders/committers/confess/#/
- New project wizard
- We need to cleanup the different overlapping project wizards
- What shall we do with our current CDT Launches?
- Launchbar is the first step
- Bugzilla "mentoring" tag
- Committers should suggest to help/mentor someone that tries to fix particular bugs
- Next gathering: hackathon?
- Elena will see if Blackberry can hold a day of presentations around CDT
- Conclusion
18:00
- Summit dinner. Great company and good food.
Attendees
- Marc Khouzam - Ericsson
- Community, Debug, Multicore, Visualizer, Tracing
- William Riley - Renesas
- Debug (Embedded), Multicore, Tracing, UX, Codan
- Marc-Andre Laperle - Ericsson
- Tracing, Debug, Community, Editor, Refactoring, Codan, Build, UX
- Andrew McLachlan - Analog Devices
- Tracing and Debug
- Srinivas Gudla - Xilinx
- Tracing, Visualizer, Multicore and Debug
- Sergey Prigogin - Google
- Parser, Indexer, Refactoring, Codan
- Doug Schaefer - QNX/BlackBerry
- Everything. Mainly Remote Launching, Qt, UX.
- Greg Watson - IBM
- Remoteness and target management
- Jeff Johnston - Red Hat
- Remote Launching, Debug
- Alena Laskavaia - QNX/Blackberry
- UX, Launch, Debug, Codan, Build
- Vladimir Prus - Mentor Graphics
- Everything
- Wyatt Spear - University of Oregon
- Performance analysis, tool integration
- Mohamed Azab - Mentor Graphics
- UX, Multicore, Codan, Parser, Indexer.
- Appa Rao Nali - Xilinx
- Tracing, Visualizer, Multicore Debug
- Yufen Kuo - Cavium
- Tracing, Remote Profiling, Remote Launching
- Jesper Eskilson - IAR Systems
- Most things
- Roland Grunberg - Red Hat
- Linux Tools Project
- Martha Benitez - Red Hat