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