On 5/23/22 20:40, Kevin Fenzi wrote:
So, just replying here since this is a nice monster of a thread. ;( First, just to clear up some previous coments, shim does build against the oldest stable Fedora in koji and then is manually tagged into newer ones. This is not at all a good process. It only gets a bodhi update for the one release (and sometimes not even that), so it never gets good testing. It requires manual intervention from releng each time there's an update. I think the only reason this has kept going is that shim is very small and simple and updates rarely. If we need to do this for tons of openjdk updates, we really should revisit the process, although I am not sure how to make it more open to testing and less a burden on releng. ;(
Thanx for bringing up additional details!
Next, My understanding of the current process for openjdks (openjdki?): for each openjdk: Build dyanmically linking against system libraries in all fedoras. Submit to TCK and wait for them all to process. Fix any TCK failures and repeat Once there's no failures, push the builds to updates Is that right? And keeping the dynamic builds passing is taking more cycles than you have to give for the number of jdks?
super correct.
What about the possibility of adding CI _upstream_ to test against the dynamic version? Then TCK failures would be caught upstream and not downstream where it's a lot of work for you to fix?
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. 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.
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. TYVM! _______________________________________________ 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
