| [cross-project-issues-dev] Neon.3 Update Problems |
|
Hi, 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, |