An alternative way could be make master/trunk branch a dev branch and allow all PRs to checked in, at the same time, maintain a stable branch which you can cut release (as release manager) and pick up PRs that you carefully reviewed. - This is the Apache way and I guess can achieve the same goal.
That would simplify accepting PRs since the uniformed will probably continue to submit against master. This would make that behavior workable. Semantically, I would have to wrap my head around the notion that the master is not the master but a development branch. But even old dogs can learn new tricks with enough time.
I can see how this works well into a release strategy. But what about uses who want to work from clones or forks?
I have some doubts: If an an end-user clones or forks the change, it would still default to creating only the master branch. You would not want users working on the master branch, you would want them to be working in the stable branch. There could potentially bad changes on the master.
Is there a way to force the initial branch to be the stable branch instead of master.
If they make changes that they want to submit on the stable branch branch, it seems to me that you have essentially the same communication problem. They would need to transfer their changes to the master branch before creating the PR. Is that right?
Another nit and this is just probably due to my fumble fingers: I often get weird things happening when I add changes to branches, then squash them into the stable branch (master in this case). At that point the histories of the two branches have diverged. I can usually reuse the old branch by rebasing and pushing the branch with --force. But the history will still not be 100% the same as the stable branch. If I lose confidence in the content of a development branch (which is fairly often), I usually just delete the branch and recreate it clean. But we cannot do that if master is the stable. We can't delete master can we? There are ways to force to branches to be identical (in both content and history) but I would have to get used to doing that.
It seems that this strategy adds some nice simplifications in one area but at least raises some questions in others. Perhaps GIT power users could answer all of those questions (but let's place not clutter up the list by solving the full workflow here. Please contribute your thoughts directly as comments at https://cwiki.apache.org/confluence/display/NUTTXTEST/Code+Contribution+Workflow+--+Brennan+Ashton).
