[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cross-project-issues-dev] Neon.3 Update Problems
- From: Jeff Johnston <jjohnstn@xxxxxxxxxx>
- Date: Thu, 30 Mar 2017 11:58:29 -0400 (EDT)
- Delivered-to: firstname.lastname@example.org
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 3DEDA804F0
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3DEDA804F0
- Thread-index: pF56ST/DSfUClbF7LaFkbrvVPQxtlQ==
- Thread-topic: Neon.3 Update Problems
Regarding the Linux Tools issue. This was due to the Oxygen M4 orbit repo referenced
as part of a patch that upgraded the level of docker-client.
I will cut a 5.3.1 release of Linux Tools today using the Orbit M6 repo. Can this be
aggregated or used to patch the issue?
-- Jeff J.
----- Original Message -----
> I'm concerned about the number of problems I see regarding updates to Neon.3.
> For example, the missing MPC problem:
> 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:
> 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:
> 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:
> 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:
> 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:
> 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...
> cross-project-issues-dev mailing list
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit