[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[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,
Ed