> On Tue, May 17, 2022 at 8:33 AM Stephen Smoogen <ssmoogen(a)redhat.com>
> wrote:
>
> My expectation is based on how both Python and .NET have done this:
>
> The Python team made "Fedora Loves Python": https://fedoralovespython.org/
> The .NET team maintains the Developer page for .NET and has a domain
> redirect to it: https://fedoraloves.net/
>
> These groups also do advocacy for Fedora in their upstreams and the
> broader communities. I don't know why you or anyone else wouldn't
> expect the packagers of OpenJDK to do advocacy for Fedora to the
> OpenJDK project and the broader Java community? Maybe they wouldn't be
> alone, but if they're not part of it, then the efforts fail.
>
This is nice example. And I agree that we shoudl do it. Issue is to findthe
time. This proposal will help OpenJDK people to find a time.
Second may be that ant, maven and jigsaw still have issues wit proper
integration to help both distribution and outside ecosystem. Pythond defintely
did better job.
As for .NET - you can not compare. The pure fact that you can dnf install it
says nothing about what lies beneath and how to properly toolchain it or
package applications for it. I had seenboth .NET packagin internals, and tried
to pack and .NET application and it was terrible. But yes, presentation is good.
>
> It is technically possible for OpenJDK to be built the way this Change
> proposes. It would require two extra packaging changes:
>
> 1. A "noautobuild" file needs to be added to opt out of mass builds and such
> 2. The DistTag would need to be dropped (no "%{?dist}" in Release)
While it will be build in the scope of
https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic then no,
it will remain %{?dist} based.
If whole https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
happens, then yes, the portbale base wil be ?dist-less, but the integration
wrapper will remain ?dist-full
>
> After that, OpenJDK would follow the same mechanism the EFI stuff
> does, where we go to "single build, multiple tags". Koji by default
shmi is probably best example you can provide. And our reason is quite same -
we have to certificate bianry. Fact that the owners of certificationallows us
to do it on our own just simplify it, but do nto lower burden.
> automatically inherits builds from the previous tag, so when new tags
> are made, the latest build in the previous tag is picked up
> automatically. As long as updates for OpenJDK are built against a
> particular tag, then the only thing left to do would be to tag in
> manually to newer Fedora release candidate tags so Bodhi can pick it
> up. Most of the workflow kinks should have been worked out with shim
> years ago.
>
> However, doing this has some terrible consequences: You cannot
> participate in mass builds. You cannot benefit from newer libraries.
> You will not benefit from system improvements. Finally, you are
> effectively isolated from the distribution.
I'm aware, and as stated many times, we are not happy from it. But we can not
find better way.
>
> But what this Change discussion tells me is that there's something
> seriously wrong with the Java TCK. I want to know if any discussion
> upstream has been had about streamlining the TCK to make it easier in
> the first place.
Hundreds:( No reasonable resoult ever come out.
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
