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,
Ed
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
