Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 24, 2022 at 5:03 PM Jiri Vanek <jvanek@xxxxxxxxxx> wrote:
> I replied it already in that thread, but happy to repeat:
> It will help, but less then it seems so.
> Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of jdk8 is in some 4 years, so fedora will suffer a bit. But it will be nice 12 TCK runs down.
> but we can not droop 11, as it is system jdk in f35
> Similarly, we couldn't introduce fresh jdk17 directly to f36 as system JDK. It needs it time to be tuned before being proposed as system jdk.
> And we can not drop java-latest-openjdk, becasue it is necessary to boot next system JDK.
> Yes, in 8 months, we would be able to drop 11. And live for 1 year only on latest and 17. Which is putting load for one year to 1/2. But the cost of not having 11 (and 8) will be felt by fedora users more, then having static jdk from repos.
> Unluckily, with new future system jdk, we will need to boostrap it by latest, keep it as secondary jdk at least for one , better two, fedora cycles, so again we will be in 3  jdks x 3 systems.
> Sure, we do not need to backport newest future system jdk to older fedoras, but usually the users want us to do so. tbh, I do not have strong preference on it. it is like 51 for backport, and 49 for not. Even with knwoledge of TCK burden.

Is this based on user requests, or is this only what you *think* users
of OpenJDK on Fedora need?
Speaking for myself, I have never used anything other than the default
"system JDK" for running Java applications on Fedora.

What would you think about the following scenario:

- Fedora X defaults to new OpenJDK LTS N
- Fedora X keeps OpenJDK LTS N-1 so it's possible to revert the change
- Fedora X+1 drops OpenJDK N-1, since the newer OpenJDK N was already
the default for one release
- do not backport OpenJDK n to Fedora X-1 and X-2
- keep java-latest-openjdk, as you seen to need this for bootstrapping
new OpenJDK releases

You could even drop java-latest-openjdk from all branches but rawhide,
since it's only needed for bootstrapping there.
This should pretty dramatically reduce the size of your test matrix.
Applying the current numbers:

- Fedora Rawhide: java-17-openjdk (default), java-latest-openjdk
- Fedora 36: java-17-openjdk (default), java-11-openjdk (in case the
default needs to be switched back), java-latest-openjdk
- Fedora 35: java-11-openjdk, java-latest-openjdk

> With much more stress about possible integration issues and with - imo(!) - considerable negative imapct to fedora.

Would this reduced set of supported OpenJDK versions, but keeping the
"latest" version, address this "considerable negative impact"?

Fabio
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux