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... > 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. > > 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 2. switching fedora to the static system libraries so you didn't need to keep the dynamic ones in sync. 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. kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
