On 10:37 Wed 11 May , Omair Majid wrote: > Hi, > > Daniel P. Berrangé <berrange@xxxxxxxxxx> writes: > > > One way to reduce this burden is to not introduce new JDKs to all > > existing Fedora streams, only add it to rawhide so certification is > > only needed once. > > > > Having said that I'm still not clear on the real impact of the > > certification. Presumably thue certification is not re-done in each > > JDK RPM re-build, nor on every RPM re-build of a library it depends > > on. If so, then do we really need to do certification for every > > Fedora release stream when adding a new JDK. Can we do a build for > > 35, certify it, and then do what is effectively no-change import > > and rebuild for 36/37-rawhide and just consider the 35-certification > > to cover those streams. > > As I understand it, the certification (TCK) is only done on a binary > level, and only applies to the OpenJDK package itself. It's not a > one-time thing when a new version of the OpenJDK is added; it needs to > be re-done on every single rebuild and/or update of OpenJDK. > > AFAIK, even if you rebuild the exact same sources with the exact same > toolchain with the exact same compiler flags, you still can't claim TCK > certification status from one build carries over to the next. > I believe there are some minor exceptions, but this is mostly correct, yes. Certainly, we'd usually prefer to re-certify than not. > If we import a binary (RPM) from one Fedora version to the other, then > we can continue claiming that the original binary is still certified. > > Please note that it has been more than 5 years since I was last involved > with Java, so things might have changed. I might also be mis-remembering > something. But hopefully that gives some context on why the > certification (TCK) burden is so huge. > Yes, I believe this is what other vendors do; each JDK build is tested on a specific platform but users may use that build elsewhere. The expectation is that someone else could reproduce the same result by using the same build on the same platform. Vendors tend to use some older OS release to increase the chance that it will still work against the few libraries that are dynamically linked (e.g. the C library). For example, Red Hat currently provides a "portable" JDK that is built on RHEL 7. The idea here is that we'd do something similar in Fedora; build on the oldest supported release, but provide that version on all supported releases. That should at least halve the testing burden, which is currently three JDKs on two or three versions of Fedora. > Omair > > -- > PGP Key: B157A9F0 (http://pgp.mit.edu/) > Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0 > _______________________________________________ > 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 -- Andrew :) Pronouns: he / him or they / them Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
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
