Hello,
I've noticed the
Subversive Connectors installation
dialog on the screenshot, so are there
any questions/problems regarding
Subversive connectors distribution?
This topic was discussed multiple
times with EMO/Wayne, so I can
continue this discussion if anybody is
interested.
Best regards,
Igor Vinnykov
Subversive Team
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:
<image001.jpg>
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