I'm starting the process of moving Wine Mono off of my personal Github account and onto the Winehq Gitlab in the organization here: https://gitlab.winehq.org/wine-mono
Obviously, I haven't gotten very far yet, as the main repo for Wine Mono itself doesn't exist, but the intent is to move every submodule that we've forked (as well as projects I've started just for Wine Mono) over to Winehq, set up CI there, and archive my Github repos. The procedure for contributing will be to fork the repository and create merge requests (which I will also do for my own contributions, once we're set up for it).
I'm also rethinking the branch structure. The Mono repo will have three mainline branches: upstream (the upstream project as it exists in the official repos), main (upstream plus further development that I will review and maintain), and wine-mono (main plus changes we have only in Wine). The "upstream" and "main" branches should be the same for any upstream that is responsive and cares about preserving ABI compatibility (right now that's just FNA and monoDX). The wine-mono branch should only exist for projects that have a general use case in which Wine's changes don't make sense (I think that's just Mono, corefx, and FNA).
The answer to "which branch should I send my MR to?" will almost always be main. There should be a very few changes on wine-mono only. The ones I can think of off the top of my head are: enabling native dll loading without coree hooks, renaming a bunch of assemblies to start with "WineMono.", winforms hooks in FNA, and proprietary media formats in FNA. Over the years we've been doing a lot of development on top of Mono that, in my opinion, belongs upstream.
I will also accept changes to Mono that have nothing to do with Wine, such as winforms changes, and I will try to keep the main branch working for use cases outside of Wine and Windows, to the extent that it's feasible (there are a bunch of configurations I can't easily test, like PowerPC, ARM, Android, and iOS, and I can't see myself doing development to support new platforms like M1). I don't know how much development interest there will be, but I seem to be in a unique position to maintain Framework Mono, and I think it is needed.
-
Esme Povirk