Hi Fred, I have just pushed a change to gerrit: https://git.eclipse.org/r/#/c/95308/
I only changed the docker repository and left the other Linux Tools features alone since they were only bumped as part of the point release to fix the Docker Tooling plug-ins. I assume I can merge the patch if the gerrit verification is successful. If this is wrong, let me know. -- Jeff J. On Wed, Apr 19, 2017 at 1:08 PM, Frederic Gurr <[email protected]> wrote: > Hi, > > Can you provide a patch for the SimRel build (branch "Neon.3_respin") > that references the new version? > > Regards, > > Fred > > 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 <[email protected] > > <mailto:[email protected]>> wrote: > > > > Frederic, > > > > There seem to have been no notes/minutes taken during the meeting: > > > > https://wiki.eclipse.org/Planning_Council/April_05_2017 > > <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 > > <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 list > >>> [email protected] > >>> <mailto:[email protected]> > >>> To change your delivery options, retrieve your password, or > unsubscribe from this list, visit > >>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > >>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > >>> > >> _______________________________________________ > >> cross-project-issues-dev mailing list > >> [email protected] > >> <mailto:[email protected]> > >> To change your delivery options, retrieve your password, or > unsubscribe from this list, visit > >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > >> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> > > > > > > _______________________________________________ > > cross-project-issues-dev mailing list > > [email protected] > > <mailto:[email protected]> > > To change your delivery options, retrieve your password, or > > unsubscribe from this list, visit > > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> > > > > > > > > > > _______________________________________________ > > cross-project-issues-dev mailing list > > [email protected] > > 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 > [email protected] > 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 [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
