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

Planning Council/April 05 2017

Logistics

Meeting Title: Planning Council Conference Call
Date & Time: Wednesday, Mar 01, 2017, at 1200 Noon Eastern
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

  • Wayne Beaton, interim chair
  • Frederic Gurr

Strategic Members

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

PMC Representatives

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

Note: "Inactive" refers to 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.

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

Previous meeting minutes

  • Review 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

TBD

Back to the top