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.me...@gmail.com> wrote: > Frederic, > > There seem to have been no notes/minutes taken during the meeting: > > https://wiki.eclipse.org/Planning_Council/April_05_2017 > 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/show_bug.cgi?id=515213 > > 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 listcross-project-issues-...@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, > visithttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > _______________________________________________ > cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, > visithttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > > _______________________________________________ > 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 >
_______________________________________________ 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
