[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jdt-dev] About Y-Builds (was Re: 4.35 Y-Build: Y20250111-1000 - BUILD FAILED)
|
Mickael,
I think you are jumping to premature conclusions here.
Before going into details, if you have evidence that everything outside the
compiler is unaffected by legal restriction, please show us. And by evidence I
mean more than a bit of hand waving from your own reasoning.
Until that is provided, I believe that *any commit* relating to an unreleased
Java version is not allowed on master, from which soon a release will be
created, and where we don't want the disclaimer
"This [...] is made available for testing and evaluation purposes only.
The code is not compatible with any specification of the JCP."
In the meanwhile we might as well take stock: Are we actually done with support
for released Java versions, or should we rather spend our energy on making
support for Java 23 really great? This can be done without any legal risks or
process concerns :) And we could even join forces rather than dividing the
community - but maybe here I'm arguing in a selfish way myself :)
Stephan
Am 17.01.25 um 12:09 schrieb Mickael Istria:
Thank you all for your answers.
I read that most of the technical or legal or process concerns seem to apply
mostly for the compiler bits such as the grammar.
My selfish motivation is the following: with the Javac backend for JDT, we may
soon want to work on support for new Java version features at DOM level and
beyond (eg core.manipulation) and have them in master ASAP, and if we're to
contribute for example some refactorings targeting next Java version, we'd
rather not have to deal with branches and feature patches when contributing to JDT.
But it seems both are not contradictory: this would still be possible to put
work regarding DOM and manipulation for next Java version in master.
So basically, let's keep things as it, and when we're to contribute stuff for
DOM or Manipulation for next Java, we'll do it on master anyway. This should
work for everyone without really changing anything. We may revisit this
discussion when we have such "DOM for next Java" contributions coming in.
Cheers,
On Thu, Jan 16, 2025 at 4:00 PM Stephan Herrmann <stephan.herrmann@xxxxxxxxx
<mailto:stephan.herrmann@xxxxxxxxx>> wrote:
Now to the question which problem we are trying to solve:
For a moment let's not talk about technical or legal issues, but about people.
Obviously we all want as many good people working on JDT as possible :)
But I have difficulties recalling the "dozens of people" who have tried to work
on unreleased java features and have gone away due to complexity of branching.
If I think long enough I could remember one person who might possibly match
this
description, his name is Mickael Istria :)
So either I just didn't notice others suffering the same fate, or we should
simply switch to helping Mickael to learn working in the branch :)
More broadly speaking, I think the interest in unreleased Java versions has
drastically dropped by the time when Oracle switched to the current release
cadence. Back at the time of Java 8 and Java 9, of course there was great
anticipation of the next big thing, both at the JDT side and even more on the
side of users, eager to work with the new version even before it was released.
My guess is that nowadays people are happy to play with the recently released
features, which will still be new to most of them perhaps several releases
back.
So why look at the one additional small set of changes that hasn't been
released
yet? Does JDT have all the IDE features we could wish for, regarding java
versions up-to and including 23? I don't know who's working on that, but there
might be enough enhancements to be done even on master?
That said, I'm all in favor of raising more public awareness, both for testing
Y-builds as well as for patch releases.
Another people-aspect is collaboration between JDT and releng. Perhaps the
perception of problems result from my requests for releng help for the branch
every now and then? But don't I ask for releng help for master much the same
way? :) -- In this regard even just a single person can make the difference. In
the past Sravan was one such person. Ed Merks has always been a solver of all
kinds of problems (and I don't recall him complaining about the branching).
Currently Hannes Wellmann has done great contributions in this area, and please
excuse if I forget someone else in this category. So perhaps we could just let
releng people speak for themselves here? Perhaps Aleksander is the one being
asked for help more than he likes? It would be only fair for him to say so.
While the grass could always be greener, and surely not everything is sunshine
and roses, perhaps we don't even have a problem of a severity that motivates
any
major changes? - Other than: more contributions! :)
best,
Stephan
Am 15.01.25 um 09:51 schrieb Mickael Istria:
> My perception is that the process to contribute to next Java version in
JDT is
> really difficult and has thrown dozens of people away. Indeed, there are
a few
> example of people working on JDT for years or on Eclipse Platform many
hours a
> week (and being paid for that) who can deal with this convoluted process
> efficiently enough for them, but there are some who just give up trying to
> contribute to next Java version because this process is too complicated and
> makes them less efficient and less successful. And I suspect this is more
people
> giving up than peopel actually contribution, and that "mainstreaming" the
> process would keep some more people around and that it would be worth the
cost
> of a few `if (Boolean.getBoolean("jdt.jepXYZ")` here and there.
> But I'm biased too.
>
> So, the few adopters who care about, can in fact take the Y builds and
> experiment.
>
>
> Well, that's one issue I'm trying to address, and IMO 1 issue that should
be the
> priority for JDT as a project if it wants to remain viable on the long
run: how
> come there are so few adopters who care about? I think the BETA branch is
one
> bit of a cause here.
>
> Cheers
--
Mickael Istria
Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat
<https://developers.redhat.com/>