Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

Scott Lewis Sat, 22 Apr 2017 20:45:50 -0700

I am not on planning council, and so have not been able to follow allthe discussion, but just to be clear ECF has this open bug for Oxygen M7:


https://bugs.eclipse.org/bugs/show_bug.cgi?id=513888

To meet this we have modified our own build to include these versionsfrom Orbit:


org.apache.httpcomponents.httpcore_4.4.6.v20170210-0925.jar
org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925.jar

It's our intention to contribute to platform an ECF build includingthese bundles during the week of May 1.

If any of this should change because of issues from this thread, pleaselet use know via bug 513888 and/or other bugs.


Scott


On 4/21/2017 2:00 PM, Jeff Johnston wrote:

Just to confirm that the change has been merged to the Neon.3_respinbranch.


-- 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>