I don't think the process is cast is stone, and so far has been highly dependent of the type of changes.
The priorities are to make it as simple for everybody, keep things reliable, and avoid having too many people having too many different versions so things get impossible to diagnose.
On my side, when I release new versions of the OSDK, the SVN is updated at the same time, I did not do it yesterday because it was a release candidate, but ISS wanted to test how it worked on Linux so I submitted the changes, the current SVN version is identical to what is on my computer.
#ifdef is only for things that we want to try that we are not sure we will want to keep, it's rarely used, and only by developers doing testing in their particular setup.
Regarding the contribution process, it's highly dependent of who, what, and the scale: I only enforce things on the version I maintain (the Windows version of the OSDK), or that have an impact on the depot (like putting things all over the place without any logic, or adding terabytes of binaries that are not relevant).
When mmu_man, jylam and iss are doing linux changes, as long as it does not have an impact on the way the windows version works, I don't care.
If I commit a change that breaks the linux version (it has happened, not on purpose, but it's hard to remember that this particular feature requires this header file on Windows and this other one on Posix machines), mmu or iss don't have to ask me if they can fix the code so it runs on their system... as long as they tell me so I can verify that it still works fine on Windows.
If it's just a small change to an existing program, posting on the forum with a patch for it is fine as well, everybody can discuss it before it makes it to the actual code repository, and depending if the person has the SVN access right or not can go make the change themselves or I can do it, since ultimately I publish the versions and I test them, that does not add anything to my workflow.
For very large changes, which can impact multiple parts of the toolchain, etc... and since most people prefer to use github, bitbucket, etc... there's nothing wrong with the modification to be done on a OSDK fork, tested and modified there, and when the person feel they have something solid, can show what they have done, everybody can fetch the code and check for issues, rebuild it and test it, etc...
It's basically how I worked with Fabrice for his tools, and recently for the C compiler: On projects the size of the OSDK, it's trivial to do a folder diff to see the changes, and it's much easier to follow the list of changes when you have separate commits that indicate what was changed in one single change list, than 20 small commits with small fixes, etc...
If you want an actual workflow to follow, I would suggest that one:
- Suggest the change you want to do, your idea, and I can tell you pretty much immediately if I will accept it or not. For example, if it involves any language that is not C or C++, installing custom build tools and new frameworks just for your feature, it's most probably going to be a big no, in which case you can totally do a complete Fork of the project and do your changes and release your versions, I can even add links to the OSDK main page to the various forks with an explanation about why it exists and the differences with my version.
- If I deem the change interesting, you can as I wrote earlier play on your machine, post on the forum with suggested changes and why you feel they are good and what the benefits are (benefits can be code performance, ease of maintenance, better compatibility, tweaks to make it easier to build for whatever platform you are using, etc...) or link to your own code repository with the changes.
- If nobody among the three or four persons who usually have opinion on that is against the change, then I can check with the author on how to bring it on board, and I'll try my best to release a new OSDK version with the changes (fully credited obviously).
Imo, that's easier to remember that your 11 point version