|Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?|
Can you provide a patch for the SimRel build (branch "Neon.3_respin")
that references the new version?
On 19.04.2017 17:27, Jeff Johnston wrote:
> Hi Ed,
> Linux tools spun a 5.3.1 release which now has a 2.3.1 version of docker
> tooling.Â The Linux tools download site has update-docker-2.3.1 and
> update-docker, both which have 2.3.1 versions of the docker.core plug-in
> and docker feature.Â Not sure why you are not seeing this.
> -- Jeff J.
> On Wed, Apr 19, 2017 at 11:13 AM, Ed Merks <ed.merks@xxxxxxxxx
> <mailto:ed.merks@xxxxxxxxx>> wrote:
>Â Â ÂFrederic,
>Â Â ÂThere seem to have been no notes/minutes taken during the meeting:
>Â Â Â Âhttps://wiki.eclipse.org/
>Â Â Â<https://wiki.eclipse.org/
>Â Â ÂI recall agreeing to provide steps for reproducing the problem so
>Â Â Âthat Thomas Watson could test if the wiring resolution fix he made
>Â Â Âfor Oxygen also solves the problem for Neon.3.Â The fact that he
>Â Â Âencountered "the mirroring problem" didn't help in that regard:
>Â Â Â Âhttps://bugs.eclipse.org/bugs/
>Â Â Â<https://bugs.eclipse.org/
>Â Â ÂIn the end, he sent me a note saying (and I quote):
>>Â Â ÂI see that now there is the same number of httpcomponents bundles
>>Â Â Âas there was in the messed up Oxygen M6 builds.Â But here my back
>>Â Â Âport of the resolver fix does not seem to have fixed the issue.
>>Â Â ÂI'm unsure if that is because it gave up with the sheer number of
>>Â Â Âbundles or if something else is going wrong.Â But at this point
>>Â Â Âthe backport of the resolver fix does not seem to be the solution
>>Â Â Âto the problem.
>Â Â ÂI assumed (wrongly I guess) that Thomas would investigate a more
>Â Â Âgeneral fix to address the wiring problem.
>Â Â ÂIn the end, I also wasn't sure which version of the docker tools is
>Â Â Âproposed for contribution to Neon.3a.Â I tried to search for update
>Â Â Âsites containing it like this:
>Â Â ÂNothing looks like a new version of 2.3.Â Goodness knows where one
>Â Â Âshould find what's being proposed for contribution...
>Â Â ÂIn any case, the proposed "solution" (A) really just changes the
>Â Â Âversion of httpclient to be one that's not broken (missing
>Â Â Âpackages), but it doesn't change the wiring problem in any
>Â Â Âfundamental way.Â There will still be the four versions that can all
>Â Â Âbe installed simultaneously, so we really should expect the same
>Â Â Âwiring problem(s).Â In fact, I believe Oxygen M6 has effectively the
>Â Â Âsame four httpcomponents.httpclient bundle as does Neon.3, so I'm a
>Â Â Âlittle suspicious whether the wiring problem is in fact really fixed
>Â Â Âeven for Oxygen.Â We won't know until M7 and that's a month away.
>Â Â ÂIt doesn't give me warm fuzzy feelings.
>Â Â ÂSo at this point it remains unclear the nature of the wiring
>Â Â Âproblem(s).Â Is it a bug? Is it fixable? Does the knowledge, will,
>Â Â Âand capacity to fix it exist?
>Â Â ÂWithout a fix to the wiring problem I think we can eliminate A as a
>Â Â Âsolution, leaving B, C, and D (i.e., focus on problem avoidance
>Â Â Âapproaches).Â But I think if the wiring problem is a bug, it will
>Â Â Âcome back, and it will raise its ugly head again when users install
>Â Â Âvarious technologies from various sources.Â To my thinking, fixing
>Â Â Âthe bug seems important.
>Â Â ÂRegards,
>Â Â ÂEd
>Â Â ÂOn 19.04.2017 12:49, Frederic Gurr wrote:
>>Â Â ÂHi Ed,
>>Â Â ÂIn the last planning-council meeting you offered to evaluate if the
>>Â Â Âfixed Linux Tools package works as expected and if there are still
>>Â Â Âwiring issues.
>>Â Â ÂCan you give us an update on the current state?
>>Â Â ÂRegards,
>>Â Â ÂFred
>>Â Â ÂOn 31.03.2017 11:14, Ed Merks wrote:
>>>Â Â ÂHi,
>>>Â Â ÂThe original thread is fractured into many threads so its kind of
>>>Â Â Âimpossible to follow each thread with a reply but I'll try at the bottom
>>>Â Â Âof this note, i.e., below the ===========
>>>Â Â ÂBut before doing that, I'd like to re-focus on the most important
>>>Â Â Âquestions: *We currently have a problem with Neon.3, will we fix it, and
>>>Â Â Âif so how will we fix it?*
>>>Â Â ÂThe discussion has quickly digressed (constructively) into solving the
>>>Â Â Âissue of how Orbit dependencies should be managed by projects and by the
>>>Â Â Ârelease train.Â Unfortunately I see this as a world hunger issue; not
>>>Â Â Âone that is easily addressed and I believe not one we can wait for in
>>>Â Â Âorder to solve the Neon.3 problem.Â Let's face it, we've not been able
>>>Â Â Âto produce a proper Oxygen milestone in months, we still don't have one
>>>Â Â Ânow, and we won't have one until next month, we hope.
>>>Â Â ÂFor Neon we've done three maintenance releases.Â Neon.1 needed a respin
>>>Â Â Âand Neon.3 looks to be in need of the same thing.Â Clearly something is
>>>Â Â Âseriously wrong.Â But if we spend our time on solving the Orbit world
>>>Â Â Âhunger issue, will we arrive at a solution in time for Oxygen, let alone
>>>Â Â Âin time to fix Neon.3?Â I am very, very doubtful.
>>>Â Â ÂAs another data point, if I install the egg-laying-wool-milk-pig for
>>>Â Â ÂNeon.3.Â The following happens.Â I'm prompted to accept this license:
>>>Â Â Â Â ÂRed Hat, Inc. licenses these features and plugins to you under
>>>Â Â Â Â Âcertain open source licenses (or aggregations of such licenses),
>>>Â Â Â Â Âwhich in a particular case may include the Eclipse Public License,
>>>Â Â Â Â Âthe GNU Lesser General Public License, and/or certain other open
>>>Â Â Â Â Âsource licenses. For precise licensing details, consult the
>>>Â Â Â Â Âcorresponding source code, or contact Red Hat, Attn: General
>>>Â Â Â Â ÂCounsel, 100 East Davie St., Raleigh NC 27601 USA.
>>>Â Â ÂI'm not sure how this license slipped into the release train.Â ÂAren't
>>>Â Â Âthere checks for this?Â (Sorry to digress, but this is also unacceptable.)
>>>Â Â ÂLaunching the final installation comes up like this:
>>>Â Â ÂClearly a disgusting mess, but I've mentioned that before and the same
>>>Â Â Âprojects are still doing the same bad things, so we clearly all accept
>>>Â Â Âthis situation as normal.
>>>Â Â ÂThe most important point here is the error log (first attachment) is
>>>Â Â Âfull of exactly the problem indications (bundle wiring problems) we
>>>Â Â Âshould have expected from the Neon.3 repository's contents, if someone
>>>Â Â Âwere to install an arbitrary combination of the repository's contents.
>>>Â Â ÂIt's really not so hard to test this!
>>>Â Â ÂIf I create the same installation with my local build of the Oomph 1.8
>>>Â Â Âinstaller---which installs my locally built version of Oomph 1.8 so the
>>>Â Â ÂOomph setup plugins are no longer disabled because I made the
>>>Â Â Âuserstorage dependency optional and eliminated the strict <=4.4 upper
>>>Â Â Âbound constraints on httpclient, which was such a bad idea I can almost
>>>Â Â Âhave a canary to think this done to solve a problem with no anticipation
>>>Â Â Âof the problems it would cause---then I can visit all the preference
>>>Â Â Âpages producing the second attached much larger log.Â It seems clear
>>>Â Â Âthat proper testing really doesn't happen for far too many projects on
>>>Â Â Âthe train.Â With distributed responsibility, no one is really responsible...
>>>Â Â Â==============================
>>>Â Â ÂOrbit Issues
>>>Â Â Â1) Respinning Linux Tools against Oxygen Mx seems to miss the point that
>>>Â Â Âwe should only distribute released versions of bundles,Â so no Neon
>>>Â Â Âbuild should redistribute any unreleased version of anything.Â If a new
>>>Â Â Âversion of something is needed for security reasons or other reasons, it
>>>Â Â Âshould be released first.Â And doing that in a maintenance train without
>>>Â Â Âtesting the overall impact is clearly something we should never do again
>>>Â Â Â(without waving a bunch of red flags of warning).Â And as Martin
>>>Â Â ÂOberhuber asks, is nothing in place to check for this?Â So suppose we do
>>>Â Â Ârespin with a fixed released version, like what we have for Oxygen M6,
>>>Â Â Âthen most likely we'd still have the problems we have in Oxygen M6 so
>>>Â Â Âwe'd need a fix to the resolver in Neon.Â Better would seem to respin
>>>Â Â Âwith the old version(s) of the Orbit bundles, but somehow we can never
>>>Â Â Âdelete the broken version from Neon and because it has a higher version
>>>Â Â Ânumber is likely to slip back in unexpected (though hopefully not, given
>>>Â Â Âthat features have pinned their bundle versions).
>>>Â Â Â2) Don't include Orbit bundles in your project's features.Â Sounds like
>>>Â Â Âa great idea, but begs endless questions, and while solving a problem
>>>Â Â Âmight well introduce more new problems than it solves.Â The first
>>>Â Â Âquestion (as Carsten points out) is how do these things end up in a
>>>Â Â Ârepository, and if they are in a repository somehow, how are they
>>>Â Â Âcategorized?Â It's hard to get them in and once you do, they're
>>>Â Â Âcategorized poorly.Â The next question is, how do they end up in the
>>>Â Â Ârelease train, if the projects that need them don't contribute them?
>>>Â Â ÂDirectly from Orbit you say?Â But which ones should be pulled in from
>>>Â Â ÂOrbit and how is that discovered?Â ÂAre those the ones the projects have
>>>Â Â Âtested against? Then there is the question of whether an installation is
>>>Â Â Âdeterministic if the bundle version isn't pinned?Â It's not; it will
>>>Â Â Âdepend on what's in the repos that are available at resolve time.Â But
>>>Â Â ÂGunnar argues that even packages are not deterministic, which I think is
>>>Â Â Âfalse: if the feature pins the bundle version and the package requires
>>>Â Â Âthe feature, then the pinned bundle is definitely in that package.Â But
>>>Â Â Âregardless, Gunnar's important point is that the runtime wiring seems
>>>Â Â Âkind of non-determinstic, and while uses constraints might help, who the
>>>Â Â Âheck understands those well, what tooling produces it correctly for us,
>>>Â Â Âis that nicely integrated in PDE, and will it be properly maintained (in
>>>Â Â Âcontrast to lower bound constraints which you can pretty expect will
>>>Â Â Âremain on whatever stale version they were initially set to).Â This may
>>>Â Â Âwell be the right direction in which to go, but getting there isn't
>>>Â Â Âgoing to be even half the fun...
>>>Â Â ÂRegards,
>>>Â Â ÂEd
>>>Â Â Â______________________________
>>>Â Â Âcross-project-issues-dev mailing list
>>>Â Â Âcross-project-issues-dev@
>>>Â Â Â<mailto:cross-project-issues-
>>>Â Â ÂTo change your delivery options, retrieve your password, or unsubscribe from this list, visit
>>>Â Â Âhttps://dev.eclipse.org/
>>>Â Â Â<https://dev.eclipse.org/
>>Â Â Â______________________________
>>Â Â Âcross-project-issues-dev mailing list
>>Â Â Âcross-project-issues-dev@
>>Â Â Â<mailto:cross-project-issues-
>>Â Â ÂTo change your delivery options, retrieve your password, or unsubscribe from this list, visit
>>Â Â Âhttps://dev.eclipse.org/
>>Â Â Â<https://dev.eclipse.org/
>Â Â Â______________________________
>Â Â Âcross-project-issues-dev mailing list
>Â Â Âcross-project-issues-dev@
>Â Â Â<mailto:cross-project-issues-
>Â Â ÂTo change your delivery options, retrieve your password, or
>Â Â Âunsubscribe from this list, visit
>Â Â Âhttps://dev.eclipse.org/
>Â Â Â<https://dev.eclipse.org/
> cross-project-issues-dev mailing list
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit