Thanks Ed. That sounds promising. Did you also test updating a broken ELWMS with the new repo?
I'm currently trying to reproduce the error with EPP packages, but so far updating a Neon.2 package to Neon.3 (with "Check for Updates") did not result in a broken MPC. Not sure what I'm missing. Regards, Fred On 25.04.2017 16:30, Ed Merks wrote: > Fred, > > Installing the Eierlegende Wollmilchsau with this additional repository > in the p2 task's repository list results in an installation without > wiring problems. > > The profile of the installation contains version 2.3.0.20170421191 of > org.eclipse.linuxtools.docker.core with is indeed the version available > in > https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/3/artifact/aggregation/final > so I think this is a good demonstration that installations creation from > this repository's contents will not have the wiring problems we've been > seeing in Neon.3. > > Regards, > Ed > > >> Ed, >> >> The temporary update site URL is: >> >> https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/3/artifact/aggregation/final >> >> >> Regards, >> >> Fred >> >> On 25.04.2017 15:13, Ed Merks wrote: >>> Fred, >>> >>> What update site URL contains these results? >>> >>> Regards, >>> Ed >>> >>> >>> On 25.04.2017 14:28, Frederic Gurr wrote: >>>> Thanks Jeff, >>>> >>>> This is the comparison of the non-unique versions list: >>>> >>>> neon3_respin aggregation build 20.04. >>>> (https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/2/artifact/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt): >>>> >>>> >>>> >>>> org.apache.httpcomponents.httpclient >>>> 4.3.6.v201411290715 >>>> 4.5.2.v20161115-1643 >>>> 4.3.6.v201511171540 >>>> 4.2.6.v201311072007 >>>> org.apache.httpcomponents.httpcore >>>> 4.3.3.v201411290715 >>>> 4.4.6.v20170210-0925 >>>> 4.2.5.v201311072007 >>>> neon3_respin aggregation build 25.04. >>>> (https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/3/artifact/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt): >>>> >>>> >>>> >>>> org.apache.httpcomponents.httpclient >>>> 4.3.6.v201411290715 >>>> 4.3.6.v201511171540 >>>> 4.2.6.v201311072007 >>>> org.apache.httpcomponents.httpcore >>>> 4.3.3.v201411290715 >>>> 4.2.5.v201311072007 >>>> >>>> >>>> So o.a.h.httpclient version 4.5.2 and o.a.h.httpcore version 4.4.6 are >>>> not in the repo any more. >>>> >>>> @All: Can someone confirm that this fixes the update problem (earlier >>>> version to Neon.3)? >>>> >>>> If it is confirmed to work, we have a fix for users that have not >>>> upgraded to Neon.3 yet. Users that already upgraded are unaffected by >>>> this. They still need to wait for a "wiring issue" fix. >>>> >>>> Regards, >>>> >>>> Fred >>>> >>>> >>>> On 21.04.2017 23:00, Jeff Johnston wrote: >>>>> Just to confirm that the change has been merged to the Neon.3_respin >>>>> branch. >>>>> >>>>> -- Jeff J. >>>>> >>>>> On Fri, Apr 21, 2017 at 4:11 PM, Jeff Johnston <jjohn...@redhat.com >>>>> <mailto:jjohn...@redhat.com>> wrote: >>>>> >>>>> I have done another respin. In this case, I rebuilt the Linux >>>>> Tools >>>>> plug-ins to use the older version >>>>> of docker-client and its dependencies which were used in >>>>> Neon.2. I >>>>> have back-versioned the >>>>> Docker tooling plug-ins to 2.3.0 with the current date. >>>>> >>>>> I have just pushed to gerrit for Neon.3_respin branch. >>>>> >>>>> https://git.eclipse.org/r/#/c/95501/ >>>>> <https://git.eclipse.org/r/#/c/95501/> >>>>> >>>>> If no-one objects, I will merge into the branch. >>>>> Verification is >>>>> already successful. >>>>> >>>>> -- Jeff J. >>>>> >>>>> On Fri, Apr 21, 2017 at 11:50 AM, Jeff Johnston >>>>> <jjohn...@redhat.com >>>>> <mailto:jjohn...@redhat.com>> wrote: >>>>> >>>>> Marcel, >>>>> >>>>> Since the respin didn't fix the problem, we will try >>>>> reverting >>>>> the docker-client dependency and keeping as much of the >>>>> added >>>>> Neon.3 functionality as possible >>>>> in place and cutting another point release. I will let the >>>>> list >>>>> know when I have something in place. >>>>> >>>>> -- Jeff J. >>>>> >>>>> On Fri, Apr 21, 2017 at 6:38 AM, Daniel Megert >>>>> <daniel_meg...@ch.ibm.com <mailto:daniel_meg...@ch.ibm.com>> >>>>> wrote: >>>>> >>>>> Adding eclipse.org-planning-coun...@eclipse.org >>>>> <mailto:eclipse.org-planning-coun...@eclipse.org> to >>>>> this >>>>> thread. >>>>> >>>>> Dani >>>>> >>>>> >>>>> >>>>> From: "Dr. Marcel Bruch" >>>>> <marcel.br...@codetrails.com >>>>> <mailto:marcel.br...@codetrails.com>> >>>>> To: Cross project issues >>>>> <cross-project-issues-dev@eclipse.org >>>>> <mailto:cross-project-issues-dev@eclipse.org>> >>>>> Date: 21.04.2017 10:17 >>>>> Subject: Re: [cross-project-issues-dev] Neon.3 >>>>> Update >>>>> Problems: To Fix and How to Fix? >>>>> Sent by: >>>>> cross-project-issues-dev-boun...@eclipse.org >>>>> <mailto:cross-project-issues-dev-boun...@eclipse.org> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> I’ll briefly summarize the discussion we had at the AC >>>>> yesterday: >>>>> >>>>> Given that we don’t know how the OSGI resolver will >>>>> behave >>>>> (even after Tom back-ported a fix to Neon) it would be >>>>> preferred to just have the Apache HTTP*** versions in >>>>> Neon.3 >>>>> that were already in Neon.2. This would to some extend >>>>> “ensure" that we are "at least as as stable as Neon.2”. >>>>> This >>>>> would require us to rollback the changes that introduced >>>>> the >>>>> latest version of HTTPClient. As far as I know this >>>>> would >>>>> especially affect the Docker Tooling. (maybe more >>>>> changes >>>>> than that are needed) >>>>> >>>>> My question to the *Docker Tooling project lead*: Is it >>>>> possible to rollback this last minute change and >>>>> postpone it >>>>> to Oxygen for the sake of making EGit, MPC, Oomph, >>>>> USS, and >>>>> Code Recommenders work reliably again - and giving us >>>>> more >>>>> trust that we won’t get into trouble with Neon.3? The >>>>> simplest solution may be to contribute the docker >>>>> tooling >>>>> from Neon.2 in Neon.3. WDYT? >>>>> >>>>> Marcel >>>>> >>>>> >>>>> >>>>> >>>>> On 20 Apr 2017, at 18:54, Frederic Gurr >>>>> <_frederic.gurr@eclipse.org_ >>>>> <mailto:frederic.g...@eclipse.org>> wrote: >>>>> >>>>> I can see >>>>> >>>>> org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925 in >>>>> >>>>> /home/data/httpd/_download.eclipse.org/linuxtools/update-docker-2.3.1/plugins_ >>>>> >>>>> >>>>> >>>>> <http://download.eclipse.org/linuxtools/update-docker-2.3.1/plugins>, >>>>> but it's definitely not in the aggregated repo. >>>>> >>>>> >>>>> On 20.04.2017 18:31, Jeff Johnston wrote: >>>>> Fred, >>>>> >>>>> The version of httpclient also changed in our >>>>> update-docker-2.3.1 repo from: >>>>> >>>>> >>>>> org.apache.httpcomponents.httpclient_4.5.2.v20161115-1643 >>>>> >>>>> to: >>>>> >>>>> >>>>> org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925 >>>>> >>>>> Not sure why this change isn't being seen as well. >>>>> >>>>> -- Jeff J. >>>>> >>>>> >>>>> >>>>> On Thu, Apr 20, 2017 at 12:21 PM, Frederic Gurr >>>>> <_frederic.gurr@eclipse.org_ >>>>> >>>>> <mailto:frederic.g...@eclipse.org><_mailto:frederic.gurr@eclipse.org_ >>>>> <mailto:frederic.g...@eclipse.org>>> wrote: >>>>> >>>>> Thanks Jeff, >>>>> >>>>> I ran a SimRel aggregation build. The only change I >>>>> can >>>>> see in the list >>>>> of "Non Unique Versions used in repository" is that a >>>>> different version >>>>> of org.apache.httpcomponents.httpcore is now used. >>>>> Instead of >>>>> 4.4.4.v20161115-1643 it's now 4.4.6.v20170210-0925. >>>>> >>>>> I compared >>>>> >>>>> _http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt_ >>>>> >>>>> >>>>> >>>>> <http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt> >>>>> >>>>> >>>>> >>>>> <_http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt_ >>>>> >>>>> >>>>> >>>>> <http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt>> >>>>> >>>>> >>>>> and >>>>> >>>>> _https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/ws/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt_ >>>>> >>>>> >>>>> >>>>> <https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/ws/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt> >>>>> >>>>> >>>>> >>>>> <_https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/ws/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt_ >>>>> >>>>> >>>>> >>>>> <https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/ws/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt>> >>>>> >>>>> >>>>> >>>>> @All: is that the intended result? >>>>> >>>>> Regards, >>>>> >>>>> Fred >>>>> >>>>> >>>>> On 19.04.2017 20:21, Jeff Johnston wrote: >>>>> Hi Fred, >>>>> >>>>> I have just pushed a change to gerrit: >>>>> _https://git.eclipse.org/r/#/c/95308/_ >>>>> <https://git.eclipse.org/r/#/c/95308/> >>>>> <_https://git.eclipse.org/r/#/c/95308/_ >>>>> <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 >>>>> <_frederic.gurr@eclipse.org_ >>>>> >>>>> <mailto:frederic.g...@eclipse.org><_mailto:frederic.gurr@eclipse.org_ >>>>> <mailto:frederic.g...@eclipse.org>> >>>>> <_mailto:frederic.gurr@eclipse.org_ >>>>> <mailto:frederic.g...@eclipse.org> >>>>> <_mailto:frederic.gurr@eclipse.org_ >>>>> <mailto:frederic.g...@eclipse.org>>>> 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 >>>>> <_ed.merks@gmail.com_ >>>>> <mailto:ed.me...@gmail.com><_mailto:ed.merks@gmail.com_ >>>>> <mailto:ed.me...@gmail.com>> >>>>> >>>>> <_mailto:ed.merks@gmail.com_<_mailto:ed.merks@gmail.com_ >>>>> <mailto:ed.me...@gmail.com>>> >>>>> <_mailto:ed.merks@gmail.com_<_mailto:ed.merks@gmail.com_ >>>>> <mailto:ed.me...@gmail.com>> >>>>> >>>>> <_mailto:ed.merks@gmail.com_<_mailto:ed.merks@gmail.com_ >>>>> <mailto: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_ >>>>> >>>>> <https://wiki.eclipse.org/Planning_Council/April_05_2017> >>>>> >>>>> <_https://wiki.eclipse.org/Planning_Council/April_05_2017_ >>>>> >>>>> <https://wiki.eclipse.org/Planning_Council/April_05_2017>> >>>>> >>>>> <_https://wiki.eclipse.org/Planning_Council/April_05_2017_ >>>>> >>>>> <https://wiki.eclipse.org/Planning_Council/April_05_2017> >>>>> >>>>> <_https://wiki.eclipse.org/Planning_Council/April_05_2017_ >>>>> >>>>> <https://wiki.eclipse.org/Planning_Council/April_05_2017>>> >>>>> >>>>> <_https://wiki.eclipse.org/Planning_Council/April_05_2017_ >>>>> >>>>> <https://wiki.eclipse.org/Planning_Council/April_05_2017> >>>>> >>>>> <_https://wiki.eclipse.org/Planning_Council/April_05_2017_ >>>>> >>>>> <https://wiki.eclipse.org/Planning_Council/April_05_2017>> >>>>> >>>>> <_https://wiki.eclipse.org/Planning_Council/April_05_2017_ >>>>> >>>>> <https://wiki.eclipse.org/Planning_Council/April_05_2017> >>>>> >>>>> <_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> >>>>> >>>>> <_https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213_ >>>>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213>> >>>>> >>>>> <_https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213_ >>>>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213> >>>>> >>>>> <_https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213_ >>>>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213>>> >>>>> >>>>> <_https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213_ >>>>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213> >>>>> >>>>> <_https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213_ >>>>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213>> >>>>> >>>>> <_https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213_ >>>>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213> >>>>> >>>>> <_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 >>>>> _cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org>> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org>>> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org>> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto: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_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>>>> >>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>> >>>>> >>>>> >>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>>>> >>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>> >>>>> >>>>> >>>>> >>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>>>> >>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>> >>>>> >>>>> >>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>>>> >>>>> <_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 >>>>> _cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org>> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org>>> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org>> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto: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_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>>>> >>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>> >>>>> >>>>> >>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>>>> >>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>> >>>>> >>>>> >>>>> >>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>>>> >>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>> >>>>> >>>>> >>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>>>> >>>>> <_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 >>>>> _cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org>> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org>>> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org>> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto: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_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>>>> >>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>> >>>>> >>>>> >>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>>>> >>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>> >>>>> >>>>> >>>>> >>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>>>> >>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>> >>>>> >>>>> >>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>>>> >>>>> <_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_ >>>>> __cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org>> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto: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_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>>>> >>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>> >>>>> >>>>> >>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>>>> >>>>> <_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 >>>>> _cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org>> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto: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_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>>>> >>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>> >>>>> >>>>> >>>>> <_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>>>> >>>>> <_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_ >>>>> __cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto: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_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>>>> >>>>> <_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 >>>>> _cross-project-issues-dev@eclipse.org_ >>>>> <mailto:cross-project-issues-dev@eclipse.org> >>>>> <_mailto:cross-project-issues-dev@eclipse.org_ >>>>> <mailto: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_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>>>> >>>>> <_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_ >>>>> __cross-project-issues-dev@eclipse.org_ >>>>> <mailto: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_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>>>> >>>>> _______________________________________________ >>>>> cross-project-issues-dev mailing list_ >>>>> __cross-project-issues-dev@eclipse.org_ >>>>> <mailto: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_ >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>>>> >>>>> -- >>>>> Codetrails GmbH >>>>> The knowledge transfer company >>>>> >>>>> Robert-Bosch-Str. 7, 64293 Darmstadt >>>>> Phone: +49-6151-276-7092 <tel:+49%206151%202767092> >>>>> Mobile: +49-179-131-7721 <tel:+49%20179%201317721>_ >>>>> __http://www.codetrails.com/_ >>>>> >>>>> Managing Director: Dr. Marcel Bruch >>>>> Handelsregister: Darmstadt HRB 91940 >>>>> _______________________________________________ >>>>> cross-project-issues-dev mailing list >>>>> cross-project-issues-dev@eclipse.org >>>>> <mailto: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 >>>>> >>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> cross-project-issues-dev mailing list >>>>> cross-project-issues-dev@eclipse.org >>>>> <mailto: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 >>>>> >>>>> <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 >>>>> >>>> _______________________________________________ >>>> 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 >>> >> _______________________________________________ >> 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 > _______________________________________________ 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