On 5/24/22 22:14, Kevin Fenzi wrote:
On Tue, May 24, 2022 at 04:57:54PM +0200, Jiri Vanek wrote:
We are testing also upstream. note that RH is maintainer of ojdk 11 and 8,
so we have to. But that is much easier, as the usptream is static within
intree libraries. And we have to run also for 17 and 18/19 as we need this
reference run, to be sure that downstream is guilty, not vanilla jdk. Thus
we test the (source x build) just once. And we can test the binary on some
known system where we always pass.
Well, I meant test the _dynamic_ build that Fedora does now...
Yy , I got that. What made you think I did not?
But in downstream, new issues usually appear due to the dynamic linking and
nature of system where only it can be installed. Also for dowstram, each
sources are built N times, so N times tested in thsoe N systems - usually
each with its psecific failures.
Could we integrate the TCK testing in our CI to save you overhead of
managing submitting, etc? Or where is the most time spent in this
workflow?
As I described in another reply, it is both human and hw. Hw to run all those swarm of builds on all platforms, and humans to verify the issue and to fix it.
TCK are very complex, and you need at least three machines in distributed system to run them. At least two of those slaves are not trivial (krb master and system where tck are running).
Generally saying, I have autoamtion to prepare that all, but second part is reproducibility. If the "non mine" setup run will fail for some reason, can I rerun it? Can I debug it? I'm finding this very hard in 3rd party hw clusters.
Would it help to have some cloud resources to do this in?
We could definitely get you access to some ec2 instances to setup a test
cluster for testing fedora builds.
it is quite hard to imagine better testing resources then I have in Red hat.
Since some amount of HW/remote 3rd party clusters - which we reached - you really do not want to continue take care of it. Also HW and infra failures will suddenly multiply to the level that tehre are still some.
And at the end, who wil watch results? And will debugging remain smooth?
So generall sayong - yes more hw would help. But with more HW one needs more pople to contorl that and fix, and to check results. So no, really since soem amount of workload, jsut more HW is not solution.
Of course that imply possible heavy reorganization JDK team in RH which cares about Fedora rpms in theirs free time, maybe have to do.
I know others have suggested fewer openjdk streams to reduce workload,
but I didn't see any reply on that from change owners.
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.
If currently we have 4 jdks on 3 fedoras with 3 primary architectures=> 36 TCK
With this shortage, we would have
2 jdks on 2 fedoras with 3 primary architectures=> 12 tck in minimum. That sound like a reasonable drop, but only for very short period of time, duriong which we will nee to have capcity reserved for ppreparation of next
system jdk: 3 jdks on 3 fedoras with 3 primary architectures=> 27 avarage, With much more stress about possible integration issues and with - imo(!) - considerable negative imapct to fedora.
ok, sorry I missed a previous reply on this. ;)
So, what would you then think about just:
1. having some cloud resources to setup a tck test env that you could
manage better than some ci somewhere and use to test fedora builds.
and
Nope. I really ahve huge HW capacity. yes, we reached its capacity. Addng more capacity woudl help, but with that will arrive need of more poeple.
2. switching fedora to the static system libraries so you didn't need to
keep the dynamic ones in sync.
Taht is first step. Maybe we will really find that we can not do it in distro, and cut of JDK packed will follow (maybe with return to dynamic linking)
but then trying to see if that reduces your workload to a sustainable
level and avoid the 'build once, certify' thing that is going to end up
being a lot of trouble.
I guess you can imagine it better then me. If we try static builds and they fails, we are back. If we try static buidls and they works, we will try the reapck. If it works, it works if not, then we will yet again cut number of jdks in
fedoras and probably return to dynamic jdks.
I really cant say. This is not exactly charted path. the reply form this trehad is pretty clear.. Similarly our standing is pretty clear.
Thanx!
J.
_______________________________________________
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
