MoM 2016 06 24

Date

Meeting was postponed to Tuesday June 28th instead, due to June 24th being a holiday in Quebec.

Attendees

• Alexandre Montplaisir (EfficiOS)
• Jonathan Rajotte (EfficiOS)
• Bernd Hufmann (Ericsson)
• Patrick Tassé (Ericsson)
• Matthew Khouzam (Ericsson)
• Marc-André Laperle (Ericsson)
• Jean-Christian Kouamé (Ericsson)
• Geneviève Bastien (Polytechnique)
• Gabriel Pollo Guilbert (Polytechnique)

Minutes

Finish assigning component maintainers

We finished assigning maintainers to all main project components. The initial list is:

analysis/graph:    Geneviève + Matthew (with Francis' support)
analysis/lami:     Alexandre + Matthew
analysis/os.linux: Matthew + Geneviève (core) + Patrick (ui)
analysis/timing:   Matthew + Bernd
btf:               Bernd + Matthew
common:            consensus
ctf:               Matthew + Marc-André
doc                goes with the rest
gdbtrace:          Patrick + Marc-André
lttng.control      Bernd + Marc-André
lttng.kernel       Alex + Geneviève
lttng.kernel.{vm+graph} (should go to os.linux soonish)
lttng.ust          Alex + Marc-André
pcap:              Marc-Andre + Matthew
rcp:               Bernd + Marc-André
releng             Marc-André + Bernd + Alexandre
ss.segment         JC + Geneviève
ss.statesystem     Alexandre + Geneviève (with Loïc as expert-consultant)
tmf.xml            Geneviève + JC
tmf.remote         Bernd + Patrick
tmf.core           consensus, except for:
    analysis       Geneviève + Matthew
    indexer        Marc-André + Patrick
    custom parser  Patrick + Bernd
tmf.ui             Patrick + Bernd

Git branching strategy for Oxygen cycle

Bernd presented his proposal for the API/branching strategy for the Oxygen cycle. After some discussions, we all agreed on the following points:

• There will be 3 maintenance releases, so each should allow for minor API changes (2.1, 2.2 and 2.3)
• The final Oxygen release should be 3.0.
• Master should track the very next release, so should not be broken to 3.0 until after the 2.3 release.
  • Transition period for all public APIs: if we want to remove APIs, they should be kept as @Deprecated until after the 2.3 release.
  • The API freeze can happen very shortly after 2.3. Allow 1-2 weeks to actually remove the @Deprecated stuff, after that removing APIs should go through the transition period, and be kept until 4.0
  • This will allow APIs to be present but @Deprecated in at least 1 stable release. That way consumers of the API that update from stable to stable releases will know about the migration path.

Other points that were mentioned:

• Messages classes and Activators should be in internal packages in general.
  • Marc-André mentioned we could eventually get rid of most Activators since they do nothing.
• Some special cases, like making existing Messages internal, could be considered on a per-case basis.
  • API filters can be used to allow these changes without having to bump the major version.
  • After 2.3, during the "clean up" period, all the API filters should be removed.

Work on generalizing "LAMI charts"

Gabriel presented his work on generalizing the user-configurable LAMI-charts into more generic charts that can be used by other TMF component.

• Introduction of a IDataModel interface, which LAMI tables, segement store tables, etc. can implement.
• User-configurable charts can then be created from any data source that implements this interface.

Some discussion about the final presentation / user experience of the feature. Also about where to put this code, probably in a new plugin (and who will be maintainer?!).

UI Responsiveness + JUL traces

Geneviève presented the last iteration of JUL integration she and Alex came up with:

• Logging can be enabled using a property (-Dorg.eclipse.tracecompass.logging=true)
• Parameters can be set using a standard JUL properties file.
• Pretty much 0 performance impact when logging is not enabled.
  • This is due to setting Level = OFF by default, and using Suppliers in log calls, so even the string concatenation is not called.

Everyone was happy with the result, and fine with the proposed implementation.

How to handle contributed external analyses

As we are starting to have more and more custom analyses (the Trace-Compass-JUL-UST trace type for example), where should all these extra analyses be held?

• Separate git tree?
• Shipped as separate p2 repo? Eclipse Marketplace?

Geneviève will investigate the possibilities.

Points deferred to next meeting

• Discussion about what is a committer, what are the roles and expectations
• How to expand using JUL tracing (integration with Activator logging, Eclipse tracing capabilities, etc)

Action items

• Alex to push a patch containing a MAINTAINERS file that will go in the git tree.
• Geneviève to investigate the different ways of packaging / providing Eclipse plugins.