Moving the mGBA submodule upstream may be worthwhile
Opened this issue · 7 comments
Draft is at mgba-emu/mgba#3272. Original post follows.
Currently, we store our mGBA C code in https://github.com/TASVideos/mgba. I've been talking to @endrift lately, and it seems like there may be some benefits to moving this code to mGBA's upstream repository.
With mGBA being under active development, improvements and fixes are happening often and these are being carried over to BizHawk's port. However, we rely heavily on endrift to know which changes are safe enough to take downstream, and which ones we should wait on. Having the code in upstream would allow the safe commits to be directly applied by endrift and the unsafe ones skipped. This also would allow endrift more flexibility in redefining mGBA's API without leaving BizHawk behind.
This wouldn't mean we're taking a completely hands-off approach to mGBA. For one, we'd still have to manage the C# mGBA code, the dll and submodule in this repo as normal. We'd still be able to file PRs to mGBA repository as necessary. Currently, changes to mGBA are relatively infrequent on our end, compared to the amount of changes happening in upstream, so moving our code upstream could potentially increase overall efficiency.
There will be a bizhawk branch, right? Will we need to clean things up before it happens?
Yep, I assume it would be stored in a BizHawk branch upstream, since BizHawk has different stability needs than mGBA's dev builds. As for whether we'd need to clean things up, @endrift could probably answer that question better than me.
It's important to keep our code in sync with upstream, working in the same git repo with minimal changes to upstream code, so that incorporating new upstream changes is as simple as a quick git merge. It's not possible to move all work upstream, because we don't maintain a stable API for the Bizhawk interface parts, so the last mile of Bizhawk interfacing C code has to be kept tightly in sync with the first mile of Bizhawk C# code.
we don't maintain a stable API for the Bizhawk interface parts, so the last mile of Bizhawk interfacing C code has to be kept tightly in sync with the first mile of Bizhawk C# code.
If our mGBA API becomes unstable on the C# side, then we'll need to adjust the C interfacing code either way. Moving the code upstream doesn't change that; it's just a different repository to point BizHawk's repository to. What it does potentially allow is for endrift to make changes to the C interfacing code and mGBA's main core code with less hassle for endrift and us.
Been busy with stuff the last...several...days so I hadn't gotten around to replying to this. My specific suggestion wasn't actually using upstream for the submodule, it was upstreaming the src/platform/bizhawk directory so that I can more easily test API changes to make sure it doesn't break downstream and the like, and it would make merging branches slightly easier in the future. Though I don't know if this is desirable, I could use CI to build mgba.dll every commit for easier testing and the like. The idea was basically to keep things closer in sync, not to remove the downstream entirely.
Will we need to clean things up for it to happen?
To some extent, yes some cleanup will be required. However, I'd like to help, at least in part so I can guide the design to make it more modern and maintainable as I push towards the 1.0 API.