Let's do a thought experiment. I've decided to use Java 11 in
EMF and have decided to change the BREEs as such. Is anyone
else's opinion binding? Maybe the Modeling PMC's opinion would
be, but I'm the lead and clearly I agree with myself. I don't
think the Planning Council's opinion is binding is it? I see no
rule stating that I'm not allowed to use Java 11 for my project
and my right to determine my project's course is very important to
me. In any case, I'm on the Planning Council, though with spotty
attendance, and I could argue that they have no jurisdiction. I
would also think that the Eclipse Packaging Project's opinion is
not the least bit relevant to me personally nor to my project.
After all, I have no binding opinion there, and if an opinion
isn't binding, it follows that it has no real weight and is of
little value. So in the end, from my project-centric view,
everyone should consider themselves lucky to have EMF at all.
What problems would this cause? Nothing serious technically.
Just change the required Java version for all products and your
done. Get over it already.
I fully agree with everything you said! Whoever is interested in having a say on EMF future should be investing in EMF (either directly hiring people or paying others to do it for them) in order to have a binding vote on EMF future. All of us the rest should be happy that we have it (or any other project!) as long as we don't invest in it somehow.
I suppose the Planning Council could decide that some old version
EMF should be on the train instead, and the EPP can then just use
that old version. But then you'd all be on your own, without new
releases nor bug fixes, ever.
Clearly it would be better if I were sensitive to the community's
opinions and needs rather than focused so much on what is and is
not binding.
Sensitivity is not helping much in attracting new people. IMHO it's counter productive to this for 2 reasons:
1. Individuals are not jumping in to help because of numerous requests, rules, demands and etc. coming from everywhere which quite often mean a whole lot of additional work for the individual for pretty much zero benefit for him/her.
2. Corporations are not jumping in to help because they know they can demand, request, try to enforce rules and that this works most of the time even if they reduce their investment or not invest at all.
So the real question is what is community? Is it every entity that makes some use and don't contribute back or the level of contribution is very unproportional? This is clearly not my understanding of "community".
_______________________________
The issue of arguments for or against a higher BREE?
The arguments for are clear. We get to use the latest and
greatest Java language features and most current Java library
classes and methods. That's strongly compelling when considered
in isolation of all other considerations.
The hint about needing Java 8 on bottom sidebar to the right
would need to mention more specifically the need for Java 11 for
some of the packages. No big deal, but would need attention.
Users launching a newly unpackaged package will be informed that
they need Java 11 (or the installer will inform them, though if
EMF changes the installer itself would need Java 11 not just Java
8). No big deal; the user will hunt down the right thing from
somewhere. A little worse is that users who install/update into an
existing installation will find their installation broken if it
was EMF involved, because nothing in the IDE will start without
EMF starting, or will find parts of the installation not working
for mysterious reasons. I suppose also no big deal when it's some
leaf component involved.
None of these consequences are ideal though and unfortunately we
have no statistics to indicate how much more likely a user is to
have Java 8 already installed versus Java 11 or higher already
installed. But clearly setting the bar higher will leave more of
the community below the bar while leaving the bar where it is now
is most definitely less disruptive.
So how would moving Eclipse IDE for Rust moving to Java 11 leave more of the community out? And of which community? Rust one ?- I doubt if anyone there cares about Java version being used at all (btw, this is probably true for C/C++ too). Eclipse IDE community? - How much anyone in the Planning Council or any other project care about Rust tooling?
Corrosion uses RLS for all the smartness and the idea is to reduce testing matrix and ease support for that project. If we want to get into theoretical discussions it's one thing but let's at least try to prove that these theories apply to the case in question.
On 02.03.2020 07:16, Aleksandar
Kurtakov wrote:
On Sun, Mar 1, 2020 at 8:28
PM Mickael Istria <mistria@xxxxxxxxxx> wrote:
No, it
is not
OK for the same arguments mentioned before.
Can you please remind those arguments? I'm curious
about which ones apply to typical Corrosion target
audience.
Also -and without any offense but more to clarify who
has influence/authority on EPP project as it's facing a
transition-, I'm curious about whether your opinion as
Planning Council member but non-EPP committers is to be
considered as binding. WDYT?
Planning Council has no bigger right over EPP (compared
to any other project) to say whether EPP project allows some
of its deliverables to require Java 11. It was specifically
discussed at the last Planning council and we agreed on that
https://wiki.eclipse.org/Planning_Council/2020-02-05#Notes
. This is a decision which should be driven by the EPP
project committers together with the not-yet-elected lead.