Good to know that SimRel has chances to survive. Personally I can hardly
imagine the future of Eclipse "classic" ecosystem without common
baseline like we have now with SimRel - things could degrade really quickly.
What I want to understand is the status of recommendation from Jonah:
"passage's p2 repo should be publishing its third party deps and it
should be possible for consumers to install passage from passage's p2
repo without requiring an orbit repo be added too".
* Is it the best practice to follow for every SimRel project?
* If so, could it be a part of Project Handbook?
I was preferring to use Orbit version of bundles (from the corresponding
Orbit contribution) since otherwise we will have a lot of duplicated 3rd
party bundles with different versions in one Eclipse Package.
Perhaps this is not a value anymore.
Please advice.
Thanks in advance,
AF
1/13/2022 5:56 PM, Aleksandar Kurtakov пишет:
On Thu, Jan 13, 2022 at 4:31 PM Ed Merks <ed.me...@gmail.com> wrote:
It's not entirely clear that a generous layer of critique and
pessimism as icing on the neglect-and-apathy cake will help the
broader team be more motivated to work toward a more viable
solution. Certainly I personally find it hugely challenging to
deal with what feels like an endless stream of disruptive changes
that percolate their way through my software stack. My projects
are like book ends on this train. Add to that playing police and
being the emergency response team, complemented by disruptive
infrastructure changes to add to the confusion, and it feels like
the goodness just never ends. I could spend some time pointlessly
pointing fingers at whom to blame for all these messy things. But
I always remind myself that when I point fingers at others,
several of my own fingers are always pointing back at me. So I
try to focus on what can be done to make things better and what I
can do to enable those.
I couldn't agree more. I started to blame myself for many failures and
they start to happen faster and faster as I clearly fail to keep the
pace and the only solution I've found is to just drop things that are
non-essential to me/my usecases/. Best way to do things better is to
just let non-viable things fall off. My experience (unfortunately!) is
that it almost never happens to get help on things until someone
getting it for free for now gets the breakage due to no longer being
kept up and warning messages seem to be just ignored.
Let's also look at some of the positives. We are building a
highly complex system, comprising a great many moving parts, with
a lot of very busy people involved, to deliver some really amazing
results, on time, four times a year. Surely we're doing a few
things right...
And we should strive for even better results. Quite often "less is more" .
Cheers,
Ed
On 13.01.2022 14:51, Aleksandar Kurtakov wrote:
On Thu, Jan 13, 2022 at 3:47 PM Jonah Graham
<jo...@kichwacoders.com> wrote:
On Thu., Jan. 13, 2022, 08:18 Aleksandar Kurtakov,
<akurt...@redhat.com> wrote:
On Thu, Jan 13, 2022 at 3:11 PM Jonah Graham
<jo...@kichwacoders.com> wrote:
On Thu., Jan. 13, 2022, 05:49 Alexander Fedorov,
<alexander.fedo...@arsysop.ru> wrote:
> Orbit essentially is like Maven Central
In that case I don't understand why do we need
Orbit at all. With the latest announcements
regarding tycho capabilities from Christoph +
lack of resources to support Orbit in safe form
it seems to be useless.
You have hit the nail on the head! Although useless
is going a little far. Orbit does not likely have a
long term future. However as there are many projects
that build from it still we need it. Also there is a
problem if multiple projects start contributing the
same version of third party lib that will hopefully
be solved in the future with PGP signing.
Orbit should not be directly contributing to simrel,
but for a variety of reasons it does (see comments in
the file)
As mentioned in the Gerrit, passage's p2 repo should
be publishing its third party deps and it should be
possible for consumers to install passage from
passage's p2 repo without requiring an orbit repo be
added too.
I know for sure that numerous projects are not quite
doing that (again see comments in orbit.aggrcon) but
hopefully at some point the temporary contribution of
orbit to simrel directly can be removed.
I would dare to say that as long as the workarounds are
in simrel nothing will get fixed - it's time to face reality.
Probably correct, but I don't have the nerve to disable (or
knowledge/time to fix) Mylyn.
^^ Exactly - the amount of complains from people not paying
attention and putting burden on others to workaround for them is
what made me lost trust that simrel is viable approach.
HTH,
Jonah
Regards,
AF
1/13/2022 1:29 PM, Gunnar Wagenknecht пишет:
On Jan 13, 2022, at 10:55, Aleksandar Kurtakov
<akurt...@redhat.com> wrote:
IMHO, people should actively remove content
from Orbit that has CVEs. Much like with any
other project. Even without replacing it with a
fixed version. We will be better with less but
trusted content than questioning ourselves for
each artifact.
Agreed. There is usually a clean-up/removal of
unneeded stuff. But the downloads are still
available for projects consuming the repositories.
>[...] That is definitely something
> new, since Orbit was a trusted source of
3rd party libraries for many
> years.
That's a misconception. Orbit essentially is
like Maven Central. Instead of Maven Artifacts
it distributes Eclipse plug-in artifacts. Maven
Central still distributes the vulnerable Log4j
version and ton of other libraries with CVEs.
Does that make it a less trustworthy source now?
I don't think so. Consumers still need to stay
on top of those.
-Gunnar
--
Gunnar Wagenknecht
gun...@wagenknecht.org, http://guw.io/
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list,
visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Aleksandar Kurtakov
Red Hat Eclipse Team
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Aleksandar Kurtakov
Red Hat Eclipse Team
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list,
visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Aleksandar Kurtakov
Red Hat Eclipse Team
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list,
visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
