This is to clarify which patches may be merged into the 3.5 branch.
* All doc changes may go in. In fact, you’re encouraged to update the branch's ReleaseNotes.rst file!
* All non-documentation patches should first receive approval from the appropriate code maintainer. (A blanket approval is acceptable for the first phase of testing.)
* If your patch fixes a major bug, it may go in.
* If your patch is to complete an *existing* feature, then it may go into the 3.5 branch. However, this feature must be completed by Phase II of testing.
Once Phase II testing starts, we will be accepting only those patches that fix major bugs.
Share and enjoy!
One more things…
To ease merging the patches into the 3.5 branch, you may use the ‘utils/release/merge.sh’ script.
Can you clarify on ‘existing feature’? Does this allow for addition of missing functionality for the openmp support such as…
Almost all of the remaining commits for clang-omp support will be implementing missing functionality in the openmp support.
I normally expect a feature to be a standalone bit of functionality — like a new optimization pass or some refactoring work. The openmp work is much bigger in nature. How many more patches will you need to commit? Are the features self contained (i.e., it doesn’t modify other parts of the compiler)?