|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:
> There seem to have been no notes/minutes taken during the meeting:
> 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:
> 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.
> 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?
>> On 31.03.2017 11:14, Ed Merks wrote:
>>> 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...
>>> 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
> 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
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
Back to the top