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

[Frederic Gurr <frederic.gurr@xxxxxxxxxxx>]

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
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>