Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [epp-dev] Moving a package to Java 11 as requirement

Thanks for the insightful and balanced response!  More comments below.

On 02.03.2020 10:21, Aleksandar Kurtakov wrote:


On Mon, Mar 2, 2020 at 9:40 AM Ed Merks <ed.merks@xxxxxxxxx> wrote:

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.

Yes, it boils down to "beggars can't be choosers."  Beggars get what they're given and can are hardly be in a position to make demands. 

So we can also be lucky that Mickael and team provide Corrosion and the Rust package and he should have the freedom do guide it as he see fit.

 

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.

This is an excellent counter point!  I invest significant effort keeping EMF compatible with really old things, and I even test that EMF actually works on such really old things:

https://ci.eclipse.org/emf/job/all-target-platforms/

But why?  What's benefit to me?  Certainly more people can use the latest EMF in more places, but I imagine that also makes everyone very complacent that their high expectations are always satisfied.

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.
Yes, corporations with pockets so deep you could put a million Euros in there and never find it again.

So the real question is what is community?
Everyone.
Is it every entity that makes some use and don't contribute back or the level of contribution is very unproportional?
Yes, even the beggars are part of the community.
This is clearly not my understanding of "community".
Certainly the greater community could benefit from being a greater community!  Being sensitive to the beggars and freeloaders is not necessarily a good thing.  It just encourages them.  It's a point well taken.
 

_______________________________

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 arguments against are less clear. 

Consider the packages page:

  https://www.eclipse.org/downloads/packages/

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?
It's just an issue of how likely is it that people will have problems because they need to install a newer Java version or will even realize they have problems because they don't have a newer Java version.
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).
Mickael will understand this community best and I have not argued they he should not move to Java 11.  If that's best for his development and his community he should be free to do what he feels is best.  I've merely pointed out some things to consider while making that decision.
Eclipse IDE community? - How much anyone in the Planning Council or any other project care about Rust tooling?
Indeed, it's a pretty tiny part.  But a cool part.
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.
 
Yes, although this thread started, I've seen Gunnar suggest that all packages move to Java 11 for 2020-06.  I'm not at all convinced that that's such a great idea.


On 02.03.2020 07:16, Aleksandar Kurtakov wrote:


On Sun, Mar 1, 2020 at 8:28 PM Mickael Istria <mistria@xxxxxxxxxx> wrote:


On Fri, Feb 28, 2020 at 9:27 AM Daniel Megert <daniel_megert@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.
 
_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/epp-dev


--
Alexander Kurtakov
Red Hat Eclipse Team

_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/epp-dev
_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/epp-dev


--
Alexander Kurtakov
Red Hat Eclipse Team

_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/epp-dev

Back to the top