View source for Planning Council/April 05 2017

== Logistics ==

{| cellspacing="0" cellpadding="4" border="1"
|-
| Meeting Title: 
| '''Planning Council Conference Call'''
|-
| Date &amp; Time: 
| Wednesday, Mar 01, 2017, at [http://www.timeanddate.com/worldclock/fixedtime.html?year=2017&month=03&day=01&hour=12&min=0&sec=0&p1=179 1200 Noon Eastern]
|- valign="top"
| Dial in: 
| (See [[Asterisk]] service for complete details on SIP, potential new numbers, phone mute commands, etc.)

Phone Numbers: (Check [[Asterisk/Numbers]] for more or current phone numbers.)
:'''For all phone lines: Participant conference extension: 710 then enter pin  35498'''
* Ottawa (local call in Ottawa) 1-613-454-1403
* North America (toll free) 1-866-569-4992
* Germany (local call anywhere in Germany) +49-692-2224-6059
* France (local call anywhere in France) +33-17-070-8535
* UK (toll free) 0800-033-7806
* Switzerland (local call anywhere in Switzerland) +41-44-580-2115

* SIP clients: 
:call 710@asterisk.eclipse.org, then enter pin 35498.

|}

== Members and Attendees  ==

=== Eclipse Foundation ===
* Y Wayne Beaton, interim chair
* Y Frederic Gurr
* Y Mickael Barbero

=== Strategic Members ===
* N CA Technologies 
* N CEA LIST 
* N Codenvy, S.A. (Tyler Jewell) 
* N Ericsson AB (<strike>Marc Khouzam</strike> Marc-Andre Laperle)
* Y IBM (Thomas Watson)
* N itemis AG (Alexander Nyssen)
* Y OBEO (Melanie Bats)
* N Oracle (Neil Hauge) 
* N Red Hat, Inc. (Nick Boldt)
* N Robert Bosch GmbH 
* Y SAP SE (Stephan Merker)

=== PMC Representatives ===
* N Business Intelligence and Reporting Tools (BIRT) PMC (Gary Xue) 
* N Data Tools Platform PMC (Brian Payton) 
* N Eclipse Cloud Development PMC (Martin Lippert)
* Y Eclipse Project PMC (Dani Megert)
* N IoT 
* N LocationTech Technology 
* Y Eclipse Modeling Project PMC (Ed Merks) 
* N Mylyn (Application Lifecycle Tools) PMC (Sam Davis)
* N PolarSys 
* N Eclipse Runtime Project (RT) PMC (Ian Bull)
* N Eclipse Science 
* N Service Oriented Architecture PMC (Adrian Mos) 
* N Technology PMC (Chris Aniszczyk) 
* Y Tools Project PMC (Doug Schaefer)
* N Eclipse Web Tools Platform Project (WTP) PMC (Carl Anderson)

<small>Note: "Inactive" refers to [http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic Strategic Members] or PMCs we have not heard from for a while and have been unable to convince to participate. Those members can become active again at any time. Contact Wayne Beaton if questions.</small> 

<small>Note: feel free to correct any errors/omissions in above attendance record.</small><br/><small>Y = Yes, attended</small><br/><small>N = No, did not</small><br/><small>R = regrets sent ahead of time</small><br/><small>D = delegated</small><br/><small>X = not expected</small>

== Previous meeting minutes ==

* Review [[Planning_Council| previous meeting minutes]] if you'd like. That is, review them before the meeting, but if questions or issues with previous minutes, this would be a good time to bring them up. 

== Agenda ==
* Finalize our plans with regard to a July ''Java 9 Release''
* Neon.3 Update Problems: To Fix and Howto Fix?

'''The Neon.3 update problems'''

The first symptom seen was that the Marketplace was not showing anymore in the Help menu in Neon.3. This seems to be due to a broken Orbit bundle that got into the Neon.3 release train repository: org.apache.httpcomponents.httpclient 4.5.2 which does not include the fluent API among others.
This was introduced in Neon.3 by the Linux Tools project while upgrading the level of docker-client referenced the Oxygen M4 Orbit repo to get the httpclient.

This leads to two different points:
1. How to resolve right now the problem for Neon.3 ? What should we do to not anymore include the broken httpclient version in Neon.3?
2. What we should do to prevent this in our future releases: How Orbit dependencies should be managed?

'''1. How to resolve the problem for Neon.3 ?'''	

Several options for resolution were proposed on the mailing lists: 	

A. Respin against Oxygen Mx Orbit: 
Jeff Jonhson proposed to respin Linux Tools based on the Oxygen M5 Orbit. This means distributing an unreleased version of a bundle.

B. Respin with the old version of httpclient:
Needs a Neon.3 Orbit Service Release containing only the 4.3.6 version of httpclient.
Needs a respin of Linux Tools to downgrade the version
But the other depending projects will not be updated and so the MPC will still not work for end user after the update. 

C. Respin with the two versions	of httpclient:
Needs a Neon.3 Orbit Service Release containing the old 4.3.6 version and the fixed 4.5.2 version of httpclient.
In theory the two httpclient bundles should be able to work side-by-side but we've seen a lot of wiring issues in Oxygen due to the mix.

D. Respin with only the new fixed version of httpclient:
Needs a Neon.3 Orbit Service Release containing only the 4.5.2 version of httpclient.
Needs a respin of all the depending projects (Marketplace?) to update their ranges to the new 4.5.2 version minimum and force the update.

Service release builds for Orbit ?
One point was also about that service release builds for Orbit could be dropped in the future: https://bugs.eclipse.org/bugs/show_bug.cgi?id=509412#c19

David Williams confirmed that in the past, there was always a maintenance build in Orbit when it was required.

'''2. How Orbit dependencies should be managed?'''

The fact is that many integration problems occurred during these last months in the SimRel. 
Today we rely on the manual labor of our package maintainers.
From the Neon.3 problems, another discussion was initiated, I tried here to list the different proposed solutions: 

A. Be sure of the Orbit milestones: 
Roland Grunberg proposed to make sure that the Orbit milestones aren't harmful to begin with. For future release they would use separate branches. For Neon.3, they had no initial plan to release Orbit builds at the beginning which contribute to the previous exposed problem.

B. Check that 3rd party libs for SimRel come from Orbit.

C. A tool to check consistency a kind of “SimRel consistency check”. 

D. The individual projects should not be allowed to contribute Orbit bundles to SimRel: SimRel aggregator should pull in the required Orbit bundles alone.

E. Don't include Orbit bundles in project's features:
It is not necessary to include deps in features as p2 will install them. David Williams answered that this could make builds and installs non-deterministic especially with third party jars. This means that tests should be done based on the "project's repository" and others from the "Sim. Release repository".

F. Communication/synchronization effort is necessary to harmonize versions across feature.xml of all participating projects.

G. Have an integration test suite that SimRel projects can contribute their own test bundles to and that runs against the finished packages. These integration tests should cover basic user stories.

H. Requiring projects on the train to have proper package uses constraints for all their bundles.

== Notes ==

=== Java 9 Update ===

Only projects that contribute something that is Java 9 related should be included in this update release.

Wayne asked if this means that users will get Java 9 updates as a matter of course (i.e. as part of the natural update process).

Dani stated that the Java 9 support for JDT will be made available with the Java 9 release and then we'd have time between then and the Oxygen.1 release in September to fix issues. Ed then asked if we want to include the Java 9 support in the official repository so that it will automatically update onto users workstations. The implication being that on the release date, the JDT Java 9 support will not have enjoyed the level of testing that other projects have via the many multiple milestones. While beta support for Java 9 has been available for some time, only proactive developers who have added it to their own environments have done real testing.

The discussion lead to a suggestion that we should issue the initial Java 9 support in a separate repository (i.e. a separate Java 9 p2 site) and continue to distribute it via Marketplace. (Wayne) ''Can we include it in an update to the Oxygen repository as an optional feature (i.e. a feature that won't automatically be updated on user workstations?''

Can we combine a separate install step with a community marketing push?

Dani noted that we're currently making the Java 9 support in JDT available via a separate repository because of licensing restrictions on the specification. For legal reasons, we can't include the implementation in our milestone builds.

We did not arrive at any sort of conclusion. Time is getting tight, we'll have to decide what we're going to do on the next call.

=== Neon.3 is broken ===
Melanie proposed some process changes for future releases on the mailing list.

Update releases must be encapsulated. i.e. use the repository related to the release for builds (don't use the Oxygen repo to build artifacts for deployment in to Neon).

Melanie proposed some options to mitigate the problems with the Neon.3 release.

Ed agreed to provide steps for reproducing the problem so that Thomas Watson could test if the wiring resolution fix he made for Oxygen also solves the problem for Neon.3.

=== Other ===

The Eclipse Planning Council approved participation by the Eclipse LDT project in Oxygen. The project's bits have been included in builds since the beginning of the Oxygen development cycle, but the project team missed announcing their participation by the M4 deadline.