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
