On Wed, May 25, 2022 at 9:38 AM Jiri Vanek <jva...@redhat.com> wrote: > > > > On 5/25/22 15:28, Neal Gompa wrote: > > On Wed, May 25, 2022 at 9:17 AM Jiri Vanek <jva...@redhat.com> wrote: > >> > >> > >> > >> On 5/24/22 22:02, Fabio Valentini wrote: > >>> On Tue, May 24, 2022 at 5:03 PM Jiri Vanek <jva...@redhat.com> 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 > >> > >> I'm not sure what you mean - from above - what is based on mine/wider > >> thinking > >> Generally waht I wrote here it is based on judgmeent of about 10 people > >> around OpenJDK pacages in Fedora. > >> The equations above are based on realistic view and experience. Do you yo > >> find some misscalcualtion above? > >> > >> I really appreciate you opinions, and would be happyt answer more > >> precisely. > >> > >> > >>> 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. > >> > >> Are you really sure? Many applications runtime requiter non system jdk, > >> so they pull it in and use, and maybe you have not even noticed. > >> Many develoeprs ahve installe dmany JDKS (in my case all from repos, > >> unless I need to compile jimage) and the switch as needed. > >> > >>> > >>> 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 > >> > >> This is possible solution. It will lower the TCK burden to aprox 3/5 with > >> lost of most widely used JDKs from repositories. > >> I'm open to this proposal. But the removal will hurt and way back will be > >> much harder then swithing static builds back to dynamic. > >>> > >>> You could even drop java-latest-openjdk from all branches but rawhide, > >>> since it's only needed for bootstrapping there. > >> > >> Taht is very valid point. Cost is it will force huge number of uses to > >> download 3rd party latest STS jdk. it is where all new features live. > >>> 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 > >>> > >> > >> it is a bit less then I wrote, - about 3/5 of current load but do yoreally > >> wish to cut all those jdks from fedora? > >> To me the static repacked build sill somehow seems as smaller evil then > >> drop practically all interesting jdks out of distro. > >> > >> So here I need to rephrase your question - is it based on your's thinking > >> or on what fedora users really needs? > >> I think the oposite - they need all jdks which are around. Proeprly > >> integrated with system. How they are built .. they do not care. > >> If update to neewer Fedora wil lmake some older JDK disapear, or if need > >> of new one will force me to update Fedora when I don't want or cant. I > >> call it much worse user expereince > >> > > > > What about only making the older JDKs use bundled static libraries, > > and the latest LTS and STS versions continue to use dynamic? That > > would significantly cut down TCK versions and allow you to focus > > dynamic support where it matters (latest Java runtime code). > > Quite a fresh thinking! > > What about all jdks except system one being static (and repacked), but the > system one dynamic. That can go below 1/2 of QA runs, without any cut of jdks > in fedora. > There exists Quite a high risk, that the system jdk will trasnfer form static > to dynamic in some point (or oposite), and that will lead to unknown new > issues prety late in lifecycle.
I did think of that, that's why I figured doing the latest STS and LTS, because it ensures the STS->LTS bootstrap is going to be reasonable. It can also be coupled with switching the system JDK to the latest LTS. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
