Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] [eclipse.org-planning-council] Solve Neon.3 problems
> integrate the fix in a temporary Equinox branch  (Equinox committer help required)

Please see https://bugs.eclipse.org/bugs/show_bug.cgi?id=514149#c16

Dani



From:        Mikaël Barbero <mikael@xxxxxxxxxxx>
To:        Eclipse Planning Council private list <eclipse.org-planning-council@xxxxxxxxxxx>
Cc:        "eclipse.org-architecture-council" <eclipse.org-architecture-council@xxxxxxxxxxx>
Date:        20.04.2017 11:52
Subject:        Re: [eclipse.org-architecture-council]        [eclipse.org-planning-council] Solve Neon.3 problems
Sent by:        eclipse.org-architecture-council-bounces@xxxxxxxxxxx



(cc AC mailing list as this is our main topic for today's call)

It seems that nobody's sure about this fix. So I think the idea would be
  • integrate the fix in a temporary Equinox branch  (Equinox committer help required)
  • respin a Neon.3 simrel build with the following changes (Frederic / Eclipse Foundation will do the respin)
    • Reference to Equinox + fix update site (Equinox committer should push a patch to simrel, on branch Neon.3_respin)
    • Reference Orbit update site with the 2 versions of HTTP components (Is this update site ready to be consume? If no, I will open a bug against orbit asking for a build of http://download.eclipse.org/tools/orbit/downloads/drops/R20170307180635/with the two versions of org.apache.httpcomponents.httpclient (4.3.6 and 4.5.2).
  • Testing (Help expected from AC/PC members and affected projects we know so far: Linux Tools, Code Recommenders, MPC, Oomph, USS)
Depending on the outcome of the testing, some affected projects may need to do some changes and thus change their contribution to Neon.3 respin. We may have to trigger several Neon.3 simrel build and loop on the testing.

Mikael


Le 20 avr. 2017 à 11:09, Daniel Megert <daniel_megert@xxxxxxxxxx> a écrit :

As said before, that fix most likely does not fix the wiring issue. Quote from Ed's note:

In the end, he sent me a note saying (and I quote):

I see that now there is the same number of httpcomponents bundles as there was in the messed up Oxygen M6 builds.  But here my back port of the resolver fix does not seem to have fixed the issue.  I'm unsure if that is because it gave up with the sheer number of bundles or if something else is going wrong.  But at this point the backport of the resolver fix does not seem to be the solution to the problem.


Dani



From:        Mikaël Barbero <mikael@xxxxxxxxxxx>
To:        Eclipse Planning Council private list <eclipse.org-planning-council@xxxxxxxxxxx>
Date:        20.04.2017 11:04
Subject:        Re: [eclipse.org-planning-council] Solve Neon.3 problems
Sent by:        eclipse.org-planning-council-bounces@xxxxxxxxxxx




I should have added +1 for solution C along with the backport of the Equinox fix to Neon (https://bugs.eclipse.org/bugs/show_bug.cgi?id=514149#c8)

Le 20 avr. 2017 à 10:45, Daniel Megert <daniel_megert@xxxxxxxxxx> a écrit :

> +1 for solution C.

If I understood Ed's pervious e-mail correctly, this might not work due to the wiring issues.

Dani



From:        Mikaël Barbero <mikael@xxxxxxxxxxx>
To:        Eclipse Planning Council private list <eclipse.org-planning-council@xxxxxxxxxxx>
Date:        19.04.2017 18:48
Subject:        Re: [eclipse.org-planning-council] Solve Neon.3 problems
Sent by:        eclipse.org-planning-council-bounces@xxxxxxxxxxx



+1 for solution C.

-10 for solution A.

0 for B and D.

Cheers,
Mikael

Le 19 avr. 2017 à 18:17, Wayne Beaton <wayne@xxxxxxxxxxx> a écrit :

I really hate to assume lazy consensus on this one. Does anybody have anything to add?

Can I at least get a couple of +1s on Melanie's recommended solution?

Only two of these solutions could fix the problem, the preferred one would be the C. Respin with the two versions of httpclient.

Wayne


On 06/04/17 08:06 AM, Mélanie Bats wrote:
Hi,

As proposed yesterday, I start this thread to track what would be done to solve the Neon.3 problems.

During the call I listed all the possible solutions :

A. Respin against Oxygen Mx Orbit

B. Respin with the old version of httpclient

C. Respin with the two versions    of httpclient

D. Respin with only the new fixed version of httpclient

Only two of these solutions could fix the problem, the preferred one would be the C. Respin with the two versions of httpclient.

The main issue at the moment with that solution is to fix the wiring issues existing while the two different versions of httpclient are installed.

A fix is available for the Linux Tools, Ed Merks proposed during the meeting to produce an aggregate to test, then test if this fix solves the problem and if he can reproduce the wiring issue. A work should be done also to fix the wiring issue which exists also on Oxygen.

If you have any comments/news about this thanks to use this thread.

Cheers,

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxxto request removal.

Mikaël Barbero
Eclipse Platform Developer & FEEP Technical Leader
Eclipse Foundation
E: mikael@xxxxxxxxxxx
T: (+33) 642 028 039
[attachment "signature.asc" deleted by Daniel Megert/Zurich/IBM] _______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxxto request removal.


_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxxto request removal.

Mikaël Barbero
Eclipse Platform Developer & FEEP Technical Leader
Eclipse Foundation
E: mikael@xxxxxxxxxxx
T: (+33) 642 028 039
[attachment "signature.asc" deleted by Daniel Megert/Zurich/IBM] _______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxxto request removal.


_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxxto request removal.

Mikaël Barbero
Eclipse Platform Developer & FEEP Technical Leader
Eclipse Foundation
E: mikael@xxxxxxxxxxx
T: (+33) 642 028 039
[attachment "signature.asc" deleted by Daniel Megert/Zurich/IBM] _______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.


Back to the top