Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

Hi Fred,

I have just pushed a change to gerrit:

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@xxxxxxxxxxx> wrote:

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:
>     <>
>     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.
>     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
>>>     <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>>>     To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>>>     <>
>>     _______________________________________________
>>     cross-project-issues-dev mailing list
>>     <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>>     To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>>     <>
>     _______________________________________________
>     cross-project-issues-dev mailing list
>     <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>     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