It's probably a self-contained change given that nothing in Fedora itself can use it.

I too would be fine with recategorizing this as Self-Contained - looking forward to Wine upstream getting support for this though :)

I'm more concerned that there doesn't seem to be an account or person link to whoever submitted this to FAS, RHBZ, etc.

We don't know who they are.

To me this can't possibly be self-contained, because it proposes going against upstream kernel defaults in order to cause a module to be loaded by default on every Fedora system which will be useful only on a few of them. I don't see how that can possibly be considered anything but system-wide.

I think we can divorce the question of whether this should be a self-contained change from whether the change should be accepted, possibly with modifications.

I think it's completely fine to accept this is as a self-contained change, as the impact is limited and change itself is simple.

OTOH, I don't think we want to implement the change exactly as proposed. As AdamW wrote, the module would be loaded everywhere and used almost nowhere. But this is better discussed in the public threads when the proposal is submitted for discussion.

Trying to change its categorization to bypass our schedule rules doesn't make me happy.

A self-contained change is a change to isolated package(s), or a general change with limited scope and impact on the rest of the distribution/project. Examples include addition of a group of leaf packages, or a coordinated effort within a Special Interest Group (SIG) with limited impact outside the SIG’s functional area.

This... isn't that. It's a change to kernel behavior on at least some systems and we don't really know what cascading impact that will have.

System-wide changes involve system-wide defaults, critical path components, or other changes that are not eligible as self-contained changes.

That looks more like it to me.

I'm -1 on treating this as a Self-contained Change, at least in part because I'm not comfortable accepting it as a late submission. I have no idea what this kernel module does and trying to sneak it in under the proverbial cover of night makes me even more wary. The Change proposal even states "I have not gathered any feedback."

For the record, this change did land in time for the self-contained deadline but it was categorised as a system-wide one, and that deadline was passed. From talking to the proposal owner, this is their first time engaging in the process so they defaulted to this category. They are fine to retarget it to F44 if that's the correct category, but wanted to propose this be re-categorised as a self-contained one to make F43 if it is suitable for this definition.

Hi there,

I am the NTSYNC proposal owner.

Many thanks for your help, Moloney!

In regards to a self-contained change vs. a system-wide one, I personally think this would make more sense as a system-wide one. I can't deny this, since it touches in parts of kernel, which is basically the most important thing of Fedora as a distribution. Like pointed out earlier, I indeed started this a system-wide one, but I was not aware of the deadline (it's my first time participating in the Change process), so I proposed to re-categorize it as a self-contained change to, well, meet the deadline.

I am personally fine with keeping this as a system-wide one, but since it is a simple thing as enabling a kernel module which, as pointed out in my change, could make Fedora the first distro to push out this module (ahead of the upstream Wine merge), I would like to take this opportunity and seek an exception from FESCo in regards to having this proposal accepted as a system-wide one after the deadline.

From what I've heard, there's (so far) very minimal negative feedback about the use of the module (such as causing problems with very specific games/apps, whereas in many others it helps a bunch). It is currently in an experimental stage (in the sense that it only works for people that seek out to use experimental Wine patches, but the kernel module itself is complete AFAIK). It's difficult to get too much feedback on this topic since it requires WIP patches to enable it (from upstream Wine), but you can take a look at some places I linked in the proposal for some more information/feedback-gathering places.

As far as I understand the Change process, if FESCo hypotetically approves this to discussion, it would still be discussed and veto-ed by the community, so having the possibility to discuss this now wouldn't necessarily mean it would be approved.

My concern is that if this gets post-poned to Fedora 44 it will not make too much sense for Fedora to be the distro to enable it, since many things will probably happen by then and Fedora wouldn't have the space and time to say "hey, we're innovating in this!" (upstream Wine will probably have that merged and maybe the kernel module would be enabled by default for everyone until then).

It's fine if this proposal gets post-poned to F44, since it is not critical in any way, but I think the timing for Fedora to be the early adopter of this kernel module is with the release of F43. :)

Many thanks to all of you.

(By the way, I was thinking that to get in touch with FESCo would mean a very formal proccess with a "The council will decide your fate." vibe, but it is very simple and open. Once again, thanks!)

@epictux123

If it's not useful to Fedora in general (only useful if you're using a specially-built set of WINE packages), then I can tell you now that it's unlikely to be accepted for F43 anyway.

What I'd advise you to do is to set up a Fedora COPR repository with the modified kernel and a version of WINE with those patches applied and then advertise this repository on the Fedora Devel mailing list and Fedora Discussion. You can get feedback from people willing to experiment without needing to put experimental code into Fedora yet. Then you can land it with more confidence in Fedora 44.

@sgallagh

Hi there, thanks for your repsponse.

To be clear, the code that is in the kernel is not experimental AFAIK. It has been accepted into kernel stable releases. It works normally when modprobe-ing the module. The proposal is only about the kernel module, and not the Wine patches.

The intention here is to get the kernel module enabled at this time, so Fedora users can benefit when the merge request in upstream Wine is eventually merged (which I suspect will happen before F44 release).

To use NTSYNC currently (on games, at least), users tend to use either https://github.com/GloriousEggroll/proton-ge-custom, https://github.com/Frogging-Family/wine-tkg-git or another community-made build.

If the kernel module is enabled, but the required Wine experimental patches (from the Wine code base, and not from the kernel module code), it will simply do nothing.

My intention is for Fedora to be the first distro to enable the kernel module as to encourage Wine/Proton developers to do more things related to NTSYNC (Fedora tends to be the early adopter of many things). Otherwise, NTSYNC would only get more attraction when it's enabled on the kernel side for everyone on all distros, which I think will take a while. Enabling the kernel module by default would eliminate one of the current hurdles to use NTSYNC, which could encourage other distros/developers to do more work related to it. :)

As I said earlier, I think that if this is post-poned to F44 then probably by then it wouldn't be relevant to try to enable this kernel module for Fedora users, since other things will probably happen until then.

Thanks once again.

There is a naming confusion here. The module is enabled. It's just not loaded by default. The proposal is about loading it automatically.

The reason why Stephen thinks this should be a system-wide change, and what also makes the proposal not very desirable, is loading of the module everywhere. If that is changed to some form of opt-in, both issues should be fixed. So in general I think the proposal should be amended to say that /usr/lib/modules-load.d/ntsync.conf will owned by the wine package (or some related subpackage). (Also note the changed location to the appropriate directory.)

The problem is that this module is only useful if wine makes use of it. But the wine PR seems to be stuck a bit. Even if it merged very soon, I'm not sure that'd be in time for F43. And it doesn't make much sense to advertise the feature in a fedora release if we don't have a wine version that'll use it. Thus, this should be coordinated with the wine release. (For early adopters who pull in wine from some external location, the same configuration change should be done there, so that users get ntsync loaded automatically.)

I still very much think we should be discussing this on the mailing list. Wider input would be useful.

If Wine supported it, it would probably ship the required snippet without us discussing it, and that's fine.

The merge request to Wine for this functionality doesn't seem likely to land anytime soon (https://gitlab.winehq.org/wine/wine/-/merge_requests/7226).

I think it'd be reasonable and welcome to have a change proposal for such a change in wine (the new functionality and automatic loading of the module). For people interested in gaming this is can be a very big feature.

So in general I think the proposal should be amended to say that /usr/lib/modules-load.d/ntsync.conf will owned by the wine package (or some related subpackage). (Also note the changed location to the appropriate directory.)

If someone doens't have wine installed, but has, say, the Steam flatpak with Proton, this won't help, right?

Hi there,

Thank you all for your input.

I was going to point out exactly what Matt justed pointed out: making this a self-contained change wouldn't suffice because there are multiple ways to use Wine, some of which don't include RPM or Flatpak packages (such as using GE-Proton, a custom Wine build with direct executables).

Someone installing Steam via RPM Fusion doesn't have wine as dependency, for instance, so for this to work it would make more logical sense to enable it on a global scale and early adopters can then use it with custom builds. This should not hurt the distro in any way, since like I said this requires experimental patches from Wine, but the kernel module itself should be completely fine (the kernel module does not contain experimental code, as it's on stable kernel versions). Fedora enabling it would just eliminate a hurdle to use it, and early adopters could then provide valuable feedback for Wine devs. The feature would still be opt-in since it requires a custom Wine build to do that.

I agree with zbyszek that we should discuss this on the mailing list where the input is wider. As I understand it, having approval from FESCo for the exception to consider a system-wide change does not necessarily mean the proposal will be approved; it's just an approval to start the discussion proccess, which I think would be very valuable right now.

Thanks once again to you all.

I'd suggest getting the Wine maintainer involved as a change (co-)owner if this is what is blocking the change from being implemented anyway.

The problem here is not needing the WIne maintainer as a co-owner, but rather the issue is how the implementation should occur because as a self-contained change it would probably not suffice the proposal's fundamental idea.

My intention here is to get an approval from you guys so we can move this to the mailing list and get wider input there (possibly people could also discuss the self-contained vs. system-wide type there too).

This was discussed during the FESCo meeting yesterday:
AGREED: change should be system-wide and submitted for f44 thru normal processing flow (+6, 0, -0)