This is not how a change proposal works. Please follow the process as documented here: https://docs.fedoraproject.org/en-US/program_management/changes_policy/

@ngompa

I'm not a Fedora developer, I have no knowledge of Fedora processes or anything.

This is a valid concern and a serious proposal and the fact that you've rushed to close it without e.g. even discussing it speaks volumes about your goodwill towards Fedora end users. That's quite sad and appalling but whatever. You may as well close the bug report as well. I will try to abstain from touching this bug tracker from now on considering how this proposal has been dealt with.

The FESCo tracker is used for us to vote on changes after they've been discussed with the community on the devel@ mailing list. It doesn't start here.

I'm not trying to dismiss the validity of the proposal. In fact, I want to see it happen myself. @zbyszek had been doing some work on this front a while ago.

I'm not a Fedora developer, I have no knowledge of Fedora processes or anything.

That's fine, that's why I gave a link to the actual changes policy so that if you want to see this happen, you can propose it properly.

Can't think of anything else. The whole infrastructure is now ready for this, it's all about changing a few strings in the kernel spec file.

This is not true either. Right now the kernel cannot load zstd compressed kmods directly, so that means it has to be decompressed before loading them. That will be fixed hopefully in 5.17 or 5.18.

This is not true either. Right now the kernel cannot load zstd compressed kmods directly, so that means it has to be decompressed before loading them. That will be fixed hopefully in 5.17 or 5.18.

I've been using ZSTD compression for kernel modules since 5.14 or even earlier if I'm not mistaken. Everything just works. Yes, I'm a Fedora user but I use the vanilla kernel on my desktop for multiple reasons.

Yeah, it works now because in userspace it decompresses the modules before handing it up the kernel, which is more expensive than loading the xz compressed modules straight into the kernel (which is what we do now).

Yeah, it works now because in userspace it decompresses the modules before handing it up the kernel, which is more expensive than loading the xz compressed modules straight into the kernel (which is what we do now).

In my testing the kernel with ZSTD modules boots leaps and bounds faster despite not having native support for the compression format.