Re: [cross-project-issues-dev] Neon.3 Update Problems

[Roland Grunberg <rgrunber@xxxxxxxxxx>]

On Thu, 2017-03-30 at 17:11 +0200, Ed Merks wrote:
> 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/#ms
> g_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.

Agreed. I should have just let the M4 (this seems to be when the broken
httpclient 4.5.2 was first introduced) build slip and release later
rather than have something adopted that would cause more problems.
While we can provide guidance on what builds are safe to use or not, if
we can't fully control what ends up referenced, then we (particularly
myself) on the Orbit side need to do more to make sure our milestones
aren't harmful to begin with.

For future releases, we'll use separate branches so we can be a lot
more selective about what gets in. This wasn't currently in use as
there was no initial plan to release Orbit builds for Neon.3. However
as the contributions began to add up there were requests for a Neon.3
build containing some of the new bundles and the only things we could
reference were the Oxygen milestones.

> 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/#ms
> g_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://downlo
> ad.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...

Yes, it looks like the update-neon-docker site was built based off of a
pre-M6 Orbit build. As Jeff suggested, a rebuild against Oxygen M6 on
Linuxtools' end can pick up the fixed httpclient so if re-doing
aggregation is possible, this should resolve issues with httpclient
that arose from the missing packages.

-- 
Roland Grunberg