[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cross-project-issues-dev] PlatformRel vs SimRel vs Orbit Abolishment frustration / Xtext leaving SimRel (again) ?!?
|
Hi Christian,
first of all I could understand that its frustrating if one feels
actually overwhelmed by releng tasks but I think you are not alone with
that.
So the same applies for people managing the releng tasks for orbit and
platform and this was taken in the past and for sure it was comfortable
for the consumers but I think we have reached a point where it becomes
prominent that it is hard to keep up with this good-old times:
- serve CVEs impacting a lot of projects arise every day and we need to
become faster here, there are often huge delays until they show up in
orbit, with log4shell the update was outdated a few hours later because
of another important CVE fixed and so on
- New Java versions are released a lot more often and many OSS projects
don't want to take the effort to support older versions
For supporting old versions, as you have written, this is a choice of
the project and I honestly don't understand the complains, for me there
are two options:
1) drop the support for old versions and if no one complains be happy
about saving you a lot of useless effort
2) if users are really addicted to old versions ask them to help with
supporting that or pay for it so you can acquire more resources
Interestingly, for platform often there *are* complains but asking for
someone to step up and help often results in silence... in the end it
was not /that/ impossible to upgrade.
About the OOMPH part (as it was already mentioned twice here) I'm a bit
confused, from what I understand OOMPH is based on eclipse so it could
pull in whats necessary from the m2e bundles and should all be set for
the new target location types (that what these extension points are for
isn't it?). If anything hinders us to do so we should find a solution
for that instead of waiting to implement just another implementation of
the same thing.
As a last note:
As Xtext is an eclipse project you can always request Orbit of adding
*any* dependency but be aware that this must be driven by you (e.g
providing patches).
Am 07.04.22 um 04:54 schrieb Christian Dietrich:
Hi all, my frustration of the current state has cost me another
sleepless night and thus i need to start this discussion again.
All of the following statements are subjective and describe my personal
view and option and feelings.
Trigger was
https://www.eclipse.org/lists/cross-project-issues-dev/msg19066.html but
is just another big drop to barrel to overflow.
What is it about:
- PlatformRel: Release of the basic eclipse platform and jdt on a
regular basis
- SimRel: All project release together with PlatformRel in versions that
work together. This requires the projects to "paying attention" to
ensure this holds true.
- Orbit: Central place to pull 3rd dependencies from. This avoid each
and every project packaging their own stuff and makes it possible for
projects with the same dependency to work together seemlessly.
Projects: Eclipse has projects with
- some budget
- a limited budget (i would categeorize Xtext with 4-6 days a month here)
- basically no buget
Projects and values:
- Some projects value support for older platform and java versions,
others dont
- Some projects "pay attention", others dont
Xtext: what do i do for Xtext
- work with community
- fix bug
- develop some smaller features
- pay attention
- fix broken Jenkins files cause infrastructure changes
- test against upstream platform and jdt
- bump versions of 3rd party dependencies
- contribute to upstream project
- ....
What makes me frustrated:
I have the feeling that i spend 95% of my buget to accommodate for
upstream infrastructure changes so that there is basically no time left
for bugfixes or features. The 3 month simrel also adds time pressure to
that "paying attention" if you take it serious.
The trigger(s):
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=568936 with a cleanup
process in orbit we have to deal with stuff disappearing from orbit. it
is clear that this is a debt in orbit and i am ok with spending a 2/3
month worth of budget to accomodate for it.
- https://www.eclipse.org/lists/cross-project-issues-dev/msg19066.html /
https://bugs.eclipse.org/bugs/show_bug.cgi?id=579574
the 2nd one is the defacto abolishment of orbit.
So if Xtext uses ASM and Platform/JDT uses ASM and they should work
together we need to uses the same ASM.
What does this mean for Xtext
- We need to be able to support older platforms and java versions with
newer tycho versions + the work for Jenkins file to make this possible
(8 different builds)
- We need to find out how to use the p2 maven feature from oomph (at a
first glance i could not find an option) or replace oomph with target
files.
- Alternatively we can stop supporting more than 1 platform or Java
versions.
I cannot tell how much work this will be because i am neither a tycho
nor a Jenkinsfile nor an Oomph expert. I also have no pointers where to
copy & paste from to make my life easier with that.
So i dont know if i can make this possible with the budget i have (even
less i can imagine projects with much less budget can do)
So what can i do:
- support only latest greated and pass the ball downstream
- pull Xtext out of simrel and with it all of its dependencies (that
would also include lsp4e for example)
- stay in simrel but stop "paying attention" and if stuff works together
Alternatives:
- why no keep orbit as place for 3rd party dependencies. I dont know
what would need to be done to make use of the p2 maven feature there
instead in the projects on their own.
Thanks and regards
Christian