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

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_megert@xxxxxxxxxx> wrote:
Adding eclipse.org-planning-council@eclipse.org to this thread.

Dani



From: Â Â Â Â"Dr. Marcel Bruch" <marcel.bruch@xxxxxxxxxxxxxx>
To: Â Â Â ÂCross project issues <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-bounces@xxxxxxxxxxx




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@xxxxxxxxxxx> 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,
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@xxxxxxxxxxx<mailto:frederic.gurr@xxxxxxxxxxx>> 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>
 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>

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

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>
 Â<mailto:frederic.gurr@eclipse.org
 <
mailto:frederic.gurr@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@xxxxxxxxx<mailto:ed.merks@xxxxxxxxx>
 Â<mailto:ed.merks@xxxxxxxxx<mailto:ed.merks@xxxxxxxxx>>
<mailto: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>>
 Â<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>>>

 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@xxxxxxxxxxx>
 Â<mailto:cross-project-issues-dev@xxxxxxxxxxx
 Â<mailto:cross-project-issues-dev@xxxxxxxxxxx>>
 Â<mailto: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>>


 Â<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@xxxxxxxxxxx>
 Â<mailto:cross-project-issues-dev@xxxxxxxxxxx
 Â<mailto:cross-project-issues-dev@xxxxxxxxxxx>>
 Â<mailto: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>>


 Â<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@xxxxxxxxxxx>
 Â<mailto:cross-project-issues-dev@xxxxxxxxxxx
 Â<mailto:cross-project-issues-dev@xxxxxxxxxxx>>
 Â<mailto: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>>


 Â<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@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@eclipse.org
 Â<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@eclipse.org
 Â<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@eclipse.org
 <
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@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

--
Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt

Phone: +49-6151-276-7092
Mobile: +49-179-131-7721

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