Re: [eclipse.org-planning-council] Meeting this Wednesday

[Mélanie Bats <melanie.bats@xxxxxxx>]

Hi,

As asked by Wayne, I updated the wiki page [1] with a recap about the 
Neon.3 problems. You can also read this recap following in this mail. If 
I missed something or if you have any comments, do not hesitate to 
answer to this mail and I will update the wiki before the meeting.

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 [2].
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.

Cheers,
--
Mélanie Bats
Eclipse Modeling Consultant
+33 5 34  57 16 29
@melaniebats

*Obeo*
25 Boulevard Victor Hugo - Colomiers - France
http://www.obeo.fr

[1] https://wiki.eclipse.org/Planning_Council/April_05_2017
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=509412#c19