On 5/18/22 18:22, Fabio Valentini wrote:
On Wed, May 18, 2022 at 6:04 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
On Wed, May 18, 2022 at 11:55 AM jiri vanek <jvanek@xxxxxxxxxx> wrote:
You can imagine TCK as gigantic and pretty good testsuite, runing 24hours with quite complicated setup. The pull and setup and run is completely autoamted, but it is a lot of HW you need (all architecures x all oses x all jdks). In adition, you need human power to keep with TCK evolution, sometimes to dapt setup, and to check resutls if they fails... and.. to fix it. We have HW from Red hat, and we deal with failures we keep track with usptream and TCK evolution. But it is not easy from human resources point of view.
At this point, I'd rather have an OpenJDK in Fedora than not. If that
means switching to bundled libraries, then fine. But all bundled
libraries need to be documented in the spec file and that information
needs to be kept up to date.
Can we do this without going down the route of building only once at
one distribution tag and tagging the binary into everything else?
I agree. Can we discuss alternative routes to reduce maintenance
burden for OpenJDK than what you're currently planning for the long
term?
thanx for this understanidng:(
Maybe we can think about whether it's absolutely necessary to keep
maintaining three different LTS versions of OpenJDK? Dropping at least
java-1.8.0-openjdk would already reduce maintenance burden for OpenJDK
packages by over 25% (given that 1.8.0 seems to cause you most of the
problems recenty).
This would of course help, but I would rahter keep 4 different jdks packed once, then 1 jdk packed 4 times.
Still we will need to maintain usually 1, but very opften two system jdks, and we will need to continue maintain java-latest-openjdk as we need it to bootsrap next main jdk.
Also we need java-lates-opnjdk live in release, not jsut in buidlroot, so we can tune integration of future jdk fluently.
If statically linking against bundled versions of *some* dependencies
would really help that much, it might also be worth considering, as a
last resort, to keep OpenJDK packages in Fedora at all.
However, I personally am strongly against the "follow-up" proposal,
MoveFedoraJDKsToBecomePortableJDKs. Most importantly, the "Known
issues" section on this wiki page sounds to me like it should be
completely out of the question to actually go forward with the
proposal.
We are going to fix known issue. Unless the known issues are solved, we can not continue.
All except debuginfo are somehow solvable.
Can you please enumerate what parts of known issues toruel syou most? that would be super valuable information.
I rate them all moreover in same level, as anoying, but really fixable (not jsut workaround-able) for common benefit.
Some time ago, jiri vanek <jvanek@xxxxxxxxxx> wrote:
We realy do no like this change, but we do not see another way.
I wonder how this happened? Has this issue been brewing for a while?
We have the issues which led to this proposal since jdk 11 appeared in fedora. The issue was unluckily not getting away, and was jsut getting worse, until this proposal occured.
Or will Red Hat be downsizing the OpenJDK team in the near future? ;)
nope, but the multiplying of JDK employees is unluckily nor following multiplying of JDKs...
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
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
_______________________________________________
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
