Maintenance work is indeed not the most exciting, but it certainly is useful. In my ML git repo, I've merged unified, lua_fix and qemu branches. It's nice not having to swap branches so often! I've updated Qemu to a version that's supported. I've removed most ^M. I've made some other tidying / style changes. But, I don't believe I have any way to get these changes into Heptapod. They'd want significant test effort, too. Maybe I'm wrong and there's some process I can follow?
A "unified dev" branch would help me. Even better would be some agreed upon naming prefix to allow multiple unrelated changes to be in flight at one time. Unless branches are short lived, they run the risk of diverging too much and never getting merged. Sometimes you need long-lived branches for expensive experiments, but this is rare. Most branches should be for one feature only, never two different things in one branch. Combined, these strategies make merges much easier. A feature gets finished, merged, then the branch is never needed again. Possibly something like this: "unified/features/dos2unix_line-ending_cleanup", "unified/features/50d_fix_crash_when_enabling_sound", etc.
Since I'm using git and have done multiple large changes, I'll need to separate out the individial fixes. This is extra work I gave myself by doing things in a slightly awkward way. I am happy to do this work to get the improvements into ML. I want to do this, but I don't know if there is a way at present.
I've also been thinking about how to tame the ifdefs. This is fundamentally hard with a project like ML, where it's inevitable that some cameras will have different features, or need the same function to do subtly different things. Changing it is even harder, because you're bound to break things as you go, and automated testing for ML is another hard problem. I think moving more things into the platform dirs might improve things. You'd duplicate some code, but make the code easier to understand and change. But to test that theory, you have to do quite a lot of work to the build system. I have a good start on this. Including stopping the build making .o files all over the place; everything is created inside build/. So much cleaner. But I've only got a small piece of the old build system functionality duplicated, continuing is a lot of effort and risks diverging the repos more than I'm comfortable with. Nobody seemed interested in my changes so I've stopped working there.
