@lego @d-jsb
I think is all a matter of method --and interpretation.
This is my opinion.
The earlier you merge into FGMEMBERs the better.
Don't worry about "status" as in finished job.Why? because that way you can gain tester/debuggers on an identical code. Example:: someone debugging the FGMEMBERS -if this is behind, may produce debug reports outdated, and maybe no-longer valid. Or if problems were introduced, people will not noticed them until you actually sync the repos.
The best way to go is sync frequently, and keep it as similar as able -- and thus you can take a debug from any of the forks as a valid, and updated.
You do not need to treat forks as "branches". There are still possibility to make branches to do the "branches" work. Experimental stuff, new code, etc.
what if the thing is broken?
Not a problem!
OpenSource philosophy. If you place enough eyes into the code, no bug is a major bug. The larger your userbase is on the bleeding edge (dev front) the fast the bugs can be detected, tracked, hunted. FGMEMBERs is not a shop for finished products. As a matter of fact is the perfect opposite. It is, totally, a mechanic's Hangar. Get your stuff in there early (release early release often), keep producing and listen to the wind (a.k.a what your testers have to say).
In other words, do not get testers to discern where to get the plane. Sync early, and
make the where not a question (as in, it does not matter: it is all the same anyways). Change to a "what". What is great, what can be improved.
Once again, FGMEMBERs is not a shop of finished products. Notice we have most every aircraft I could get my hands on. Even aircraft that duly underperform. Sometimes just carcasses of planes. Get the people to engage in development. Testers: the most valuable resource.
If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it? Probably not, because if they don’t recognise their freedoms, they’ll let their freedoms fall