| Re: [cross-project-issues-dev] [eclipse.org-planning-council] Neon.3 Update Problems |
That's a good question. One could be that there was a critical / security fix that had to be adopted. And now comes the really sad story, and I'm sorry that I have to point the finger on it. In the Platform we also got forced to fetch a bundle from the Oxygen stream to be used in Neon.3 in order to provide a security fix. I have never seen an announcement from Orbit that service release builds for Orbit got dropped, but that seems to be the current reality, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=509412#c19.
Dani
From:
Ed Merks <ed.merks@xxxxxxxxx>
To:
eclipse.org-planning-council@xxxxxxxxxxx,
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date:
30.03.2017 17:11
Subject:
[eclipse.org-planning-council]
Neon.3 Update Problems
Sent by:
eclipse.org-planning-council-bounces@xxxxxxxxxxx
I'm concerned about the number of problems I see regarding updates to Neon.3. For example, the missing MPC problem:
https://www.eclipse.org/forums/index.php/mv/msg/1085206/1758538/#msg_1758538
It looks just like the problem we've been having with Oxygen M5/M6. That problem I believe traces back to a broken version of httpclient that worked its way into Oxygen M5:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=511333
Rather than immediately fixing the problem and fixing M5, the problem was allowed to propagate; weird and bizarre things were done to modify downstream code to explicitly exclude the broken version:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=511406
Of course such upper bound constraints also explicitly exclude the new fixed version when it came along, so now it seems M6 is also broken, because of wiring issues:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=513809
I think the wiring issues arose to a large extent because of the things done during M5. In my opinion what should have happened in M5 is that the Orbit bundle was immediately fixed (or reverted to the older version) and M5 was respun to ensure that no broken version of httpclient ever propagated further into the echo system. The last thing I would ever have expected (and I personally would have refused to do) is for downstream clients to make changes to explicitly exclude a broken version. Please let's never do that again. And please let's never behave as if the Eclipse Platform project's build can't be respun to fix problem. Surely we can't have a policy in place where no matter the state of the platform's build, it must remain as is, broken Orbit bundles and all.
But what seems even worse, though I don't fully understand the problem, is how this broken orbit bundle id='org.apache.httpcomponents.httpclient' version='4.5.2.v20161115-1643' got into the Neon release train repository. Given all the problems it caused in Oxygen M5 surely we should have avoided that at all costs. I suspect it came from this repository:
http://download.eclipse.org/linuxtools/update-neon-docker
I say that because that repo contains the broken version of httpclient and the versions of the docker IUs in that repo are the same as the versions in the neon release train, so it seems to me the bundles from this repo were aggregated into Neon.
So now the problems we have in Oxygen M5 and M6 are also problems for the users of Neon.3. That makes me very sad. Users expect update releases to be stable. Surely we're doing something very wrong to get into a state where a bundle known to be problematic nevertheless works its way into the final stable update of the Neon...
I don't know if the EGit update problems are at all related:
https://www.eclipse.org/forums/index.php/mv/msg/1085206/1758538/#msg_1758538
It definitely looks like a different problem, but org.slf4j.api_1.7.10.v20160921-1923 also comes from the update-neon-docker update site. And that's not a version that's in http://download.eclipse.org/tools/orbit/downloads/latest-R, i.e., it appears not to be a released version. So again, one has to wonder how this worked its way into Neon.3 causing update problems for Neon.3...
Regards,
Ed_______________________________________________
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@xxxxxxxxxxx to request removal.