I'd like to take the lead getting our stuff synched back upstream over the next few weeks. I thought I'd get the discussion going here on a few strategic matters. There has also been some
discussion in the upstream channels about libretro-mupen synchronization.
1. In case anyone's not aware, the
upstream source has been migrated to github, and now contains some additional video and rsp plugins, e.g. the ones wahrhaft was maintaining. This makes it easier than ever now to sync with upstream.
2. Paul and I formed the
mupen64plus-ae organization on github. The idea is that the organization may be easier to find, and we can collect all mupen-ae related business under one place. This is where we would house our forks of the various upstream repositories. Right now I'm using it as a sandbox to test and verify some git mechanics, so don't put any stock into it for now (i.e. don't submit pull requests).
3. I did some experimentation and discovered that it is feasible to move the plugins outside the JNI folder and still get proper Android builds. It only required a few changes to jni/Android.mk. So organizing it something like this will work, if that's what we want:
- (new repository root)
- mupen64plus-ae
- (contents of current repository, minus the jni subdirectories listed below) - mupen64plus-audio-sdl
- (contents of current jni/audio-sdl) - mupen64plus-core
- (contents of current jni/core) - mupen64plus-input-android
- (contents of current jni/input-android) - mupen64plus-rsp-hle
- (contents of current jni/rsp-hle) - mupen64plus-video-glide64mk2
- (contents of current jni/gles2glide64) - mupen64plus-video-gln64
- (contents of current jni/gles2n64) - mupen64plus-video-rice
- (contents of current jni/gles2rice)4. For best upstream synching, we should maintain our plugins as separate, independent repositories, each a fork of its upstream parent. So we'd have a git repo for mupen64plus-audio-sdl, another for mupen64plus-core, etc. We should try to keep the master branch as clean as possible to make it easy to diff/merge/cherry-pick between up- and downstream. We could generally push new changes to branches, then clean them up before putting them over to master.
5. This then leads to a big question: What do we keep in the mupen64plus-ae repository? The options that I can imagine are
A. Keep a copy of plugin source in the ae repository. This is what we're doing now. The only thing we'd change is the upstream location in the git-subtree pull script (see tools folder of current repo).
B. Remove all plugin source from the ae repository. The user would clone all the mupen64plus-ae organization's repos into a common directory, then ndk-build from the mupen64plus-ae subdirectory.
C. Same as B, but add the compiled binaries to the ae repository. That would make it much easier to traverse the git history for bisecting and so forth. The right plugin version would be associated with each commit in the ae repo.
D. Use git-submodule. I'm only saying it for completeness. Everything I read about it is that it's a nightmare to use and requires all devs to be git gurus.
I personally feel that git history traversal with the correct plugin versions is very important, so I favor options A and C. I think I lean towards option A since it keeps things simple (no change to current practice, and we wouldn't even need to reorganize directories as in item 3) and makes it easy for new devs to jump in and add fixes. I personally don't mind if the commits are messy, because I can always clean them up before synching back our own plugin fork. That would keep our fork repos clean for easy upstream synchronization and reuse by other projects (e.g. mupen64plus-pandora). To maintain cleanliness, we might consider giving only a few devs write access to the plugin forks, but support pull requests.