[
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?
|
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
and
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/
>
> 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 <mailto:frederic.gurr@xxxxxxxxxxx>> 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@xxxxxxxxx
> <mailto:ed.merks@xxxxxxxxx>
> > <mailto:ed.merks@xxxxxxxxx <mailto:ed.merks@xxxxxxxxx>>> 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>>
> >
> > 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>>
> >
> > 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@xxxxxxxxxxx
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
> >>> <mailto:cross-project-issues-dev@xxxxxxxxxxx
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
> >>> 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@xxxxxxxxxxx
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
> >> <mailto:cross-project-issues-dev@xxxxxxxxxxx
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
> >> 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@xxxxxxxxxxx
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
> > <mailto:cross-project-issues-dev@xxxxxxxxxxx
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
> > 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@xxxxxxxxxxx
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
> > 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@xxxxxxxxxxx
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
> 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@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
